[SOLVED] MCU hangs unless JLink is connected

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

  • [SOLVED] MCU hangs unless JLink is connected

    I have a strange problem with a custom EFM32LG230F128 based-design and I am getting out of ideas.

    I am using Tiny Gecko's SEGGER J-Link debugger to program my module and so far it works fine.

    Source Code: debugger.log

    1. $ JLinkExe -device EZR32LG230F128 -if swd -speed 1000 -autoconnect 1
    2. SEGGER J-Link Commander V6.52a (Compiled Oct 2 2019 09:45:00)
    3. DLL version V6.52a, compiled Oct 2 2019 09:44:47
    4. Connecting to J-Link via USB...O.K.
    5. Firmware: Energy Micro EFM32 compiled Dec 10 2012 15:59:12
    6. Hardware version: V7.00
    7. S/N: 440007513
    8. License(s): GDB, RDI
    9. VTref=3.427V
    10. Device "EZR32LG230F128RXX" selected.
    11. Connecting to target via SWD
    12. Found SW-DP with ID 0x2BA01477
    13. Scanning AP map to find all available APs
    14. AP[1]: Stopped AP scan as end of AP map has been reached
    15. AP[0]: AHB-AP (IDR: 0x24770011)
    16. Iterating through AP map to find AHB-AP to use
    17. AP[0]: Core found
    18. AP[0]: AHB-AP ROM base: 0xE00FF000
    19. CPUID register: 0x412FC231. Implementer code: 0x41 (ARM)
    20. Found Cortex-M3 r2p1, Little endian.
    21. FPUnit: 6 code (BP) slots and 2 literal slots
    22. CoreSight components:
    23. ROMTbl[0] @ E00FF000
    24. ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB000 SCS
    25. ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
    26. ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
    27. ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
    28. ROMTbl[0][4]: E0040000, CID: B105900D, PID: 003BB923 TPIU-Lite
    29. ROMTbl[0][5]: E0041000, CID: B105900D, PID: 003BB924 ETM-M3
    30. Cortex-M3 identified.
    31. > loadbin file.bin,0
    32. > r
    33. > g
    Display All

    However, as soon as the debugger is detached (JLinkExe process killed), the CPU hangs and enters an infinite loop of rebooting because of the watchdog.
    This issue is quite problematic and I have run out of clues.

    I very much appreciate your help.
  • Hello,

    Thank you for your inquiry.
    The described behaviour is expected. To handle a watchdog you can either disable it or you need to feed it regularly.
    How is described in the target devices reference manual and numerous Arm coding guides.

    Best regards,
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    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.
  • Hi Nino,

    Thanks for the reply.
    The watchdog is regularly feeded (every 32 seconds). To prove this the firmware works just fine (without the watchdog resetting the module) when the debugger is connected, that is the problem I am having. As soon as the debugger is unplugger, the module hangs...