Hello,
I have a J-Link Pro, running the J-Link gdb on Eclipse Luna Service Release 2 (4.4.2), on a STM32L151UC. When running the debug configuration on a project compiled with GNU Cross ARM GCC, the execution pauses repeatedly on a non-existing break-point on _startup.c :
Display All
And after clicking step OVER, the execution moves to another file (!) and then hitting resume makes the execution continue smoothly. After this debug session is terminated, a new attempt to run the same configuration runs up to " __initialize_hardware_early ();" (cannot step IN to that) and then reports
I tried git'ing back to older points, replacing the board or even trying another J-Link with no different results.
The only workaround I have found is that if I run a simple hello-world project (as created from the Eclipse templates for the particular device and toolchain), this executes fine and then I can execute the debugging of the big project once more.
Changing something on the big project, building and running the debug conf does not fix the problem, although this forces a reprogramming of the chip's memory. (It crossed my mind that maybe this was what the small program was helpful for)
The whole problem did not appear after any update or obvious setup change, but simply started occurring.
I would appreciate any help or ideas on what might be wrong. If you need any information from me let me know.
Edits: Describing the behavior more accurately
I have a J-Link Pro, running the J-Link gdb on Eclipse Luna Service Release 2 (4.4.2), on a STM32L151UC. When running the debug configuration on a project compiled with GNU Cross ARM GCC, the execution pauses repeatedly on a non-existing break-point on _startup.c :
C Source Code
- ...
- void __attribute__ ((section(".after_vectors"),noreturn,weak))
- _start (void)
- {
- // Initialise hardware right after reset, to switch clock to higher
- // frequency and have the rest of the initialisations run faster.
- //
- // Mandatory on platforms like Kinetis, which start with the watch dog
- // enabled and require an early sequence to disable it.
- //
- // Also useful on platform with external RAM, that need to be
- // initialised before filling the BSS section.
- __initialize_hardware_early ();
- // Use Old Style DATA and BSS section initialisation,
- // that will manage a single BSS sections.
- #if defined(DEBUG) && (OS_INCLUDE_STARTUP_GUARD_CHECKS)
- __data_begin_guard = DATA_GUARD_BAD_VALUE; //<<<<<<<<<----EXECUTION PAUSES ON THIS LINE----------------
- __data_end_guard = DATA_GUARD_BAD_VALUE;
- #endif
- ...
And after clicking step OVER, the execution moves to another file (!) and then hitting resume makes the execution continue smoothly. After this debug session is terminated, a new attempt to run the same configuration runs up to " __initialize_hardware_early ();" (cannot step IN to that) and then reports
...
Program received signal SIGTRAP, Trace/breakpoint trap.
0x4a316012 in ?? ()
The underlined part is repeated every time I click run and the execution keeps pausing....
R14(LR) = FFFFFFFF, R15(PC) = 00000000
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0xB083B500)
Performing single step...
...Target halted (PC = 0x00000002)
Reading all registers
Read 4 bytes @ address 0x00000002 (Data = 0xF004B083)
WARNING: Failed to read memory @ address 0xFFFFFFFF
Performing single step...
...Target halted (PC = 0x00000004)
Reading all registers
Read 4 bytes @ address 0x00000004 (Data = 0xFEF2F004)
WARNING: Failed to read memory @ address 0xFFFFFFFF
Starting target CPU...
...Target halted (PC = 0x4A316012)
Reading all registers
WARNING: Failed to read memory @ address 0x4A316012
I tried git'ing back to older points, replacing the board or even trying another J-Link with no different results.
The only workaround I have found is that if I run a simple hello-world project (as created from the Eclipse templates for the particular device and toolchain), this executes fine and then I can execute the debugging of the big project once more.
Changing something on the big project, building and running the debug conf does not fix the problem, although this forces a reprogramming of the chip's memory. (It crossed my mind that maybe this was what the small program was helpful for)
The whole problem did not appear after any update or obvious setup change, but simply started occurring.
I would appreciate any help or ideas on what might be wrong. If you need any information from me let me know.
Edits: Describing the behavior more accurately
The post was edited 3 times, last by Selportion ().