uC stuck in reset handler with debugger connected

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

  • uC stuck in reset handler with debugger connected

    Hi,

    i am a proud user of the j-link edu. I try to use the debugger with the Atmel SAM3X8E on a Arduino DUE board trough the SWD interface.
    I don't use any special init script. I have the strange problem that after flashing and running sometimes (8 of 10 cases) the mcu gets stuck in the reset handler. I use the standard init code of the Atmel ASF.
    If i run the board without connected debugger (no running gdb-server or j-link commander, but wired j-link) the processor runs without issue. After some random iteration of disconnecting and reconnecting the debugger, mcu board and restarting gdb-server it starts to working, and as long as i don't disconnect power at the mcu i have no problems. But as soon as i disconnect and reconnect power to the mcu it will get stuck in the reset handler if the debugger is connected.

    If the mcu is stuck i can debug it and get a halt in the following loop of the init code.

    Source Code

    1. void Reset_Handler(void)
    2. {
    3. uint32_t *pSrc, *pDest;
    4. /* Initialize the relocate segment */
    5. pSrc = &_etext;
    6. pDest = &_srelocate;
    7. if (pSrc != pDest) {
    8. for (; pDest < &_erelocate;) {
    9. *pDest++ = *pSrc++;
    10. }
    11. }
    12. [.....]
    13. }
    Display All

    the variables are as follow:

    Source Code

    1. &_erelocate = 0x200715cc
    2. &_srelocate = 0x20070000
    3. &_etext = 0x9773c

    this seems all reasonable. But

    Source Code

    1. _pDest = 0x0

    This can not happen with this code. Interrupts are turned off at this point. And it only happens if the debugger is connected. So my guess is that the debugger somehow messes with the variable?

    This is my first project with ARM mcus and external debuggers so any hint what is going on would be nice
  • Hello,

    I used the software version 6.12 and updated now to 6.14a and the problem got worse


    Could you please elaborate what exactly got worse so we can try to identify the cause?

    Best regards,
    Nino
    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.
  • previously i got it running after 4 to 5 tires with iterating powercycles now i need 7 to 8 cycles. But i was not able to find any pattern. Somehow it seems that the j-link is loosing snyc in a way, because it seems that power cycling the j-link helps..
    i think i have found a pattern:
    What i did:
    j-link and mcu are connected permanently via SWD
    1) Connect j-link with usb
    2) power up mcu --> MCU is running ok
    3) start gdb-server and connect to j-link -> MCU is halt
    4) connect to gdb
    4.1) "monitor reset"
    4.2) "load" -> flash loads successfully mcu gets to reset and gets to infinite loop

    5) exit gdb -> mcu still stuck in loop
    6) hard reset mcu -> mcu comes out of loop and runs fine
    7) start again gdb -> GDB server: WARNING: CPU could not be halted mcu runs still fine
    7.1) task kill gdb server and gdb
    8) open again gdb server
    9) Load program again like step 4) -> mcu running fine

    this is reproducible

    A other iteration:
    1) power up mcu -> mcu is running
    2) connect j-link to usb ->mcu is running
    3) start and connect gdb server -> mcu is halted (not shown in the gdb server dialogue)
    4) connect to gdb
    4.1) "monitor reset"
    4.2) "load" -> flash loads successfully mcu is stuck o runs fine, can not reproduce it reliable
    5) close gdb server -> mcu still in loop
    6) disconnect mcu from power
    7) reconnect -> mcu runs fine
    8) start connect gdb server -> mcu halted
    9) run gdb, reset and load -> mcu stuck in loop
    10) quit gdb -> mcu still in loop
    11) quit gdb server -> mcu in loop
    12) hard reset mcu -> mcu runs fine
    13) start j-link commander
    13.1) connect
    13.2) command: h -> mcu halts
    13.3) command: g -> mcu runs
    13.4) command: r -> mcu stuck in reset loop (i can not check probably, but the cpu behaves like he is in reset/ pins are in tristate)
    13.5) command: h -> mcu halted PC=0x00086F10
    13.6) command: q -> mcu resets and runs fine
    14) Start and connect gdb server
    15) start gdb -> reset, load mcu runs fine
    16) monitor reset and set break point to loop -> mcu runs fine to bp -> PC = 0x00086F10
    17) continue -> mcu runs fine

    if the mcu runs fine it runs until i power cycle the mcu
    [EDIT:] runs fine means i can flash and reset it without problems trough gdb

    so it is probably a reset problem?

    The post was edited 3 times, last by bluehazzard ().

  • Hello,

    Could you provide us with the J-Link logfiles so we can try to find the source of the issue?
    One where the Hard Fault does not get triggered and one where it does.

    A how to is described in the J-Link Manual under chapter 3.3.5.10 -logtofile: UM08001_JLink

    Here the excerpt from the manual:


    Description
    Starts the GDB Server with the option to write the output into a log file.
    If no file is given via -log , the log file will be created in the GDB Server application
    directory.

    Note: For the GUI version, this setting is persistent for following uses of GDB
    Server until changed via -nologtofile or the GUI.

    Syntax
    -logtofile

    Example
    jlinkgdbserver -logtofile
    jlinkgdbserver -logtofile -log “C:\my path\to\file.log”


    Best regards,
    Nino
    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.