J-Link GDB on Eclipse gets blocked after terminating

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • J-Link GDB on Eclipse gets blocked after terminating

    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 :

    C Source Code

    1. ...
    2. void __attribute__ ((section(".after_vectors"),noreturn,weak))
    3. _start (void)
    4. {
    5. // Initialise hardware right after reset, to switch clock to higher
    6. // frequency and have the rest of the initialisations run faster.
    7. //
    8. // Mandatory on platforms like Kinetis, which start with the watch dog
    9. // enabled and require an early sequence to disable it.
    10. //
    11. // Also useful on platform with external RAM, that need to be
    12. // initialised before filling the BSS section.
    13. __initialize_hardware_early ();
    14. // Use Old Style DATA and BSS section initialisation,
    15. // that will manage a single BSS sections.
    16. #if defined(DEBUG) && (OS_INCLUDE_STARTUP_GUARD_CHECKS)
    17. __data_begin_guard = DATA_GUARD_BAD_VALUE; //<<<<<<<<<----EXECUTION PAUSES ON THIS LINE----------------
    18. __data_end_guard = DATA_GUARD_BAD_VALUE;
    19. #endif
    20. ...
    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
    ...
    Program received signal SIGTRAP, Trace/breakpoint trap.
    0x4a316012 in ?? ()
    ...
    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
    The underlined part is repeated every time I click run and the execution keeps pausing.
    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 ().

  • Does anyone have any suspicions on where the problem may lie?
    I mean, it is not a chip fault, it is not fixed by resetting the device or even restarting eclipse or restarting the whole operating system.
    It is not fixed by changing the debugger, not fixed with changing the chip, but it is fixed if I program/debug once or twice any device with another small program.
    I think it can be only related with the eclipse plug-in of J-Link. Something non-volatile about the process. Am I wrong?
  • Hello,

    This sounds like either the application or the debug settings are not configured correctly.

    From the posted part of the GDB Server log it looks like the PC is incorrect (R15(PC) = 00000000).
    On Cortex-M its reset value is loaded from 0x00000004, but even this value does not look correct.

    Are you running your application from the internal flash?
    Could you make sure the vector table is linked to 0x00000000 (or 0x08000000)?

    Could you please provide a complete GDB Server log of a working and a not working session?

    Additionally, which eclipse plug-in are you using?
    The GNU ARM Eclipse plug-ins (gnuarmeclipse.livius.net/blog/)?
    SEGGER does not provide their own Eclipse plug-in for J-Link.

    Best regards
    Johannes
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello Johannes,

    Thank you for taking the time. So..
    From the posted part of the GDB Server log it looks like the PC is incorrect (R15(PC) = 00000000).

    On Cortex-M its reset value is loaded from 0x00000004, but even this value does not look correct.
    Indeed. I just introduced the setting to set the PC to 0x4, did not fix it.
    Are you running your application from the internal flash?
    This was the intention. The gdb reports to 'program/verify/compare' the 'flash'. How can I double-check that?
    Could you make sure the vector table is linked to 0x00000000 (or 0x08000000)?
    I attach the device.h file and the linker scripts as they were generated by the template program, is this information you need included there?
    Could you please provide a complete GDB Server log of a working and a not working session?
    Yes, please find them attached.
    Additionally, which eclipse plug-in are you using?

    The GNU ARM Eclipse plug-ins (gnuarmeclipse.livius.net/blog/)?
    Yes, this is the one, and the respective hello-test program that I am using is gnuarmeclipse.livius.net/blog/test-project/ . I also got the linker scripts and semi-hosting solution from that.

    Best regards,
    Patroklos
    Files
    • stm32.zip

      (180.36 kB, downloaded 530 times, last: )
  • Hello Patroklos,




    [img]http://forum.segger.com/wcf/icon/quoteS.png[/img]
    Quoted




    From the posted part of the GDB Server log it looks like the PC is incorrect (R15(PC) = 00000000).



    On Cortex-M its reset value is loaded from 0x00000004, but even this value does not look correct.
    Indeed. I just introduced the setting to set the PC to 0x4, did not fix it.
    That's not correct. As I wrote, the PC is loaded with the value which is read from 0x00000004.
    Normally GDB will set the correct PC itself, so you can simply remove this command

    The GDB Server log shows, that you load 0xFEF6F004 to this address, which does not look correct.
    Could you please check, that your vector table is correctly linked to the start of flash?

    Best regards
    Johannes
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello Johannes,

    Ok, I reverted that. Could you help me with checking this?
    I see on the (projectname).map output file:

    Source Code

    1. .text.NVIC_SetVectorTable
    2. 0x00000000 0x14 ./arch/stm32/driver/misc.o
    3. ...
    4. ...
    5. .isr_vector 0x00000000 0x114
    6. 0x00000000 . = ALIGN (0x4)

    In device.h:

    Source Code

    1. #define SCB_VTOR_TBLOFF ((uint32_t)0x1FFFFF80) /*!< Vector table base offset field */
    2. #define SCB_VTOR_TBLBASE ((uint32_t)0x20000000) /*!< Table base in code(0) or RAM(1) */

    and respectively on the included core_cm3.h:

    Source Code

    1. /* SCB Vector Table Offset Register Definitions */
    2. #if (__CM3_REV < 0x0201) /* core r2p1 */
    3. #define SCB_VTOR_TBLBASE_Pos 29 /*!< SCB VTOR: TBLBASE Position */
    4. #define SCB_VTOR_TBLBASE_Msk (1UL << SCB_VTOR_TBLBASE_Pos) /*!< SCB VTOR: TBLBASE Mask */
    5. #define SCB_VTOR_TBLOFF_Pos 7 /*!< SCB VTOR: TBLOFF Position */
    6. #define SCB_VTOR_TBLOFF_Msk (0x3FFFFFUL << SCB_VTOR_TBLOFF_Pos) /*!< SCB VTOR: TBLOFF Mask */
    7. #else
    8. #define SCB_VTOR_TBLOFF_Pos 7 /*!< SCB VTOR: TBLOFF Position */
    9. #define SCB_VTOR_TBLOFF_Msk (0x1FFFFFFUL << SCB_VTOR_TBLOFF_Pos) /*!< SCB VTOR: TBLOFF Mask */
    10. #endif
    Display All


    But I am not setting any of these registers in SW.
    On SystemInit(void) it is set

    Source Code

    1. SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH. */

    which is ((uint32_t)0x08000000) | 0x0
    but I guess you would like to see what happens even earlier, on the linker?

    Thank you,
    Patroklos

    The post was edited 2 times, last by Selportion ().