JLINK_IsHalted() returns ERROR

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

  • JLINK_IsHalted() returns ERROR

    I'm debugging a project with J-Link GDB Server and everything works stable (program executing and debug session running both stable).
    After I made some modifications just to source code only, I encountered an unstable debug session behavior. After some activity a debug session suspends with SIGTRAP (Trace/breakpoint trap) at address 0x0. But program continues executing and responds to external events. I press resume button in debugger and it continue working. I can even suspend it and it will stop at valid program code point. In general, this issue doesn't crash system.
    There are fragment from j-link log file:

    Source Code

    1. ... a lot of JLINK_GetHWStatus and JLINK_IsHalted ...T0284 199:445 JLINK_GetHWStatus(...) returns 0x00 (0001ms, 26422ms total)
    2. T0478 199:458 JLINK_IsHalted() returns FALSE (0001ms, 26423ms total)
    3. T0478 199:479 JLINK_IsHalted() returns FALSE (0001ms, 26424ms total)
    4. T0478 199:500 JLINK_IsHalted() returns ERROR (0001ms, 26425ms total)
    5. T0478 199:501 JLINK_ReadReg(R15) -- CPU is running
    6. ***** Error: Can not read register 15 (R15) while CPU is running returns 0x00000000 (0001ms, 26426ms total)
    7. T0478 199:502 JLINK_FindBP(Addr = 0x00000000)
    8. JLINK_ReadMemHW(0x00000000, 0x0004 Bytes, ...) -- CPU is running -- CPU_ReadMem(4 bytes @ 0x00000000) -- Data: 00 00 02 20 returns 0x00 (0000ms, 0000ms total)
    9. JLINK_ReadMemHW(0x08000000, 0x0004 Bytes, ...) -- CPU is running -- CPU_ReadMem(4 bytes @ 0x08000000) -- Data: 00 00 02 20 returns 0x00 (0001ms, 0000ms total)
    10. JLINK_WriteMemHW(0x00000000, 0x0004 Bytes, ...) -- Data: 01 00 03 00 -- CPU is running -- CPU_WriteMem(4 bytes @ 0x00000000) returns 0x04 (0001ms, 0001ms total)
    11. JLINK_ReadMemHW(0x00000000, 0x0004 Bytes, ...) -- CPU is running -- CPU_ReadMem(4 bytes @ 0x00000000) -- Data: 00 00 02 20 returns 0x00 (0001ms, 0002ms total)
    12. -- MA0 is in flash -- Unmirror addr 0x00000000 returns 0x00000000 (0003ms, 26427ms total)
    13. T0478 199:505 JLINK_GetNumWPs() returns 0x00 (0000ms, 26430ms total)
    14. T0478 199:525 JLINK_ReadReg(R0) -- CPU is running
    15. ***** Error: Can not read register 0 (R0) while CPU is running returns 0x00000000 (0000ms, 26430ms total)
    16. T0478 199:525 JLINK_ReadReg(R1) -- CPU is running
    17. ***** Error: Can not read register 1 (R1) while CPU is running returns 0x00000000 (0000ms, 26430ms total)
    18. T0478 199:525 JLINK_ReadReg(R2) -- CPU is running
    19. ***** Error: Can not read register 2 (R2) while CPU is running returns 0x00000000 (0000ms, 26430ms total)
    20. T0478 199:525 JLINK_ReadReg(R3) -- CPU is running
    21. ***** Error: Can not read register 3 (R3) while CPU is running returns 0x00000000 (0000ms, 26430ms total)
    22. T0478 199:525 JLINK_ReadReg(R4) -- CPU is running
    23. ***** Error: Can not read register 4 (R4) while CPU is running returns 0x00000000 (0000ms, 26430ms total)
    24. T0478 199:525 JLINK_ReadReg(R5) -- CPU is running
    25. ***** Error: Can not read register 5 (R5) while CPU is running returns 0x00000000 (0000ms, 26430ms total)
    26. T0478 199:525 JLINK_ReadReg(R6) -- CPU is running
    27. ***** Error: Can not read register 6 (R6) while CPU is running returns 0x00000000 (0000ms, 26430ms total)
    28. T0478 199:525 JLINK_ReadReg(R7) -- CPU is running
    29. ***** Error: Can not read register 7 (R7) while CPU is running returns 0x00000000 (0000ms, 26430ms total)
    30. T0478 199:525 JLINK_ReadReg(R8) -- CPU is running
    31. ***** Error: Can not read register 8 (R8) while CPU is running returns 0x00000000 (0000ms, 26430ms total)
    32. T0478 199:525 JLINK_ReadReg(R9) -- CPU is running
    33. ***** Error: Can not read register 9 (R9) while CPU is running returns 0x00000000 (0000ms, 26430ms total)
    34. T0478 199:525 JLINK_ReadReg(R10) -- CPU is running
    35. ***** Error: Can not read register 10 (R10) while CPU is running returns 0x00000000 (0001ms, 26430ms total)
    36. T0478 199:526 JLINK_ReadReg(R11) -- CPU is running
    37. ***** Error: Can not read register 11 (R11) while CPU is running returns 0x00000000 (0000ms, 26431ms total)
    38. T0478 199:526 JLINK_ReadReg(R12) -- CPU is running
    39. ***** Error: Can not read register 12 (R12) while CPU is running returns 0x00000000 (0000ms, 26431ms total)
    40. T0478 199:526 JLINK_ReadReg(R13) -- CPU is running
    41. ***** Error: Can not read register 13 (R13) while CPU is running returns 0x00000000 (0000ms, 26431ms total)
    42. T0478 199:526 JLINK_ReadReg(R14) -- CPU is running
    43. ***** Error: Can not read register 14 (R14) while CPU is running returns 0x00000000 (0000ms, 26431ms total)
    44. T0478 199:526 JLINK_ReadReg(R15) -- CPU is running
    45. ***** Error: Can not read register 15 (R15) while CPU is running returns 0x00000000 (0000ms, 26431ms total)
    46. T0478 199:526 JLINK_ReadReg(XPSR) -- CPU is running
    47. ***** Error: Can not read register 16 (XPSR) while CPU is running returns 0x00000000 (0000ms, 26431ms total)
    48. T0478 199:527 JLINK_ReadCodeMem(0x00000000, 0x0004 Bytes, ...) -- Unmirror addr 0x00000000 -- Read from flash cache (256 bytes @ 0x08000000) -- Data: 00 00 02 20 returns 0x04 (0000ms, 26431ms total)
    49. T0478 199:548 JLINK_ReadCodeMem(0x00000000, 0x0004 Bytes, ...) -- Data: 00 00 02 20 returns 0x04 (0000ms, 26431ms total)
    50. T0478 199:658 JLINK_ReadCodeMem(0x00000000, 0x0002 Bytes, ...) -- Data: 00 00 returns 0x02 (0000ms, 26431ms total)
    51. T0478 199:665 JLINK_ReadCodeMem(0x00000000, 0x0002 Bytes, ...) -- Data: 00 00 returns 0x02 (0000ms, 26431ms total)...
    Display All


    Something goes wrong on line 5:

    Source Code

    1. T0478 199:500 JLINK_IsHalted() returns ERROR (0001ms, 26425ms total)


    What might cause this error ? I even accept an assumption that code could fall out to incorrect execution or to address invalid memory, etc. But I can't understand how it can affect J-link and even lead it to such error ???

    The post was edited 1 time, last by artem_pisarenko ().

  • Hi,

    I assume that you are using a Cortex-M based device, correct? (STM32?)
    Do you use any low-power modes in your application?
    Do you make use of any watchdogs in your application?

    If one of both is true, could you please try out with having both disabled? Does it work correctly then?


    Best regards
    Alex
    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.
  • Thank you for answer. Yes, it's STM32F207. Actually I've integrated LwIP TCP/IP stack based on official ST's STM32F2x7_ETH_LwIP_V1.1.0 demo example. Original demo works ok, but my project doesn't, although I used the same sources files and I didn't add nothing more that could activate low-power, cpu stop or watchdog. I'm analyzing code now...
  • I found that JTAG/SWD cable was plugged incompletely. But after I fixed connection the problem was not solved, it just happen more rarely now (up to 5 minutes of stable session). Now I need much more patience to process debugging this problem. I've commented a lot of code an found that problem happen even in following case: ethernet perepherial configured partially, no FreeRTOS tasks created, FreeRTOS scheduller running (idle task executing only). Also I configured STM32 DBG_MCU to support debugging in all low power modes and checked it. (I implemented freertos idle hook which enter cpu in sleep mode, and debug session works ok.) Also I didn't found low-power modes or watchdog in any source files. It's only strange that original demo under Attolic TrueSTUDIO works stable (but I didn't tested longer then 10 mins).
    I guess it's hardware problem.
    I use STM3220G-EVAL Rev.B board, J-Link ARM V4.42c software, Windows 7 Pro SP1 64-bit.
  • Hi,

    Can you provide a project which can be used out-of-the-box and which shows the problem on an eval board?
    We also have the STM3220G-EVAL here, so it should not be a major problem to reproduce it here.


    Best regards
    Alex
    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.
  • Things become crazy more and more. Me and my collegue have been tried a lot of combinations (software, hardware, configurations, j-links) to locate root of this problem. We are able to reproduce problem with different project. We have two identical boards, two j-links (IAR and Pro). There was moment when we found that the same code works differently on different boards. But later this theory was failed. We've broken our brains to understand... to find out any regularity... I'm just tired... The nature of phenomenon is absolutely RANDOM for me.
    Can you provide a project which can be used out-of-the-box and which shows the problem on an eval board?
    We also have the STM3220G-EVAL here, so it should not be a major problem to reproduce it here.
    Unfurtunately, I can't share project, because it contains a lot of private commercial code. (If I remove those fragments, which even actually don't executing but just compile, then it will became stable. As I said before, incredible things are happen.) But even if I could give it to you, you will have all chances to run it successfully on the same board with the same j-link, the same compiler, etc. Because this project was prepared by my collegue, and when he gave it to me, it run successfully at my computer. Me and my collegue use identical boards, identical versions of compiler toolchain, identical versions of IDE, identical versions of j-link software, identical j-link adapters (actually different but we are exchanging). The only differences are OSes (Win XP 32-bit vs. Win 7 Pro 64-bit), chairs we are sitting on, keyboard, mouse, number of monitors, and our clothes.
    I have no such project which is simple enough to be possible to share with you and which reproduces problem (even at least for me).
    I think, problem resides in eval board. In STM3220G-EVAL evaluation board User Manual on page 11 you can find warning:
    Signal I2S_SD (PI3) is close to signal TCK/SWCLK of the
    JTAG/SWD interface, so to avoid possible communication
    issues on JTAG/SWD when the I2S interface is used the
    recommendations are to:
    1) Prefer usage of embedded ST-LINK/V2 to external tool
    connected on CN14.
    2) Configure PI3 GPIO in low speed (2 MHz or 10 MHz).

    We didn't use I2S. But such warning means that there are may be other still undiscovered topology "bugs" which would cause SWD communication to be affected.
    Finally, we decided to give up on this issue, because the investigation became too hard and has stalled.
  • Seems like I localized a root of problem. It's on-board external SRAM I use to store RAM data.

    I'm still not sure but you can try to reproduce the issue with these steps (you may need a lot of patience to catch it):
    1. You need J-Link ARM adapter, STM3220G-EVAL board (with default jumpers configuration !), Atollic TRUESTUDIO for STM32 Lite 2.2.0 (the only IDE/toolchain I've tested), STM32F2x7 ethernet LwIP V1.1.0 demo example from ST, network interface on PC.
    2. Connect J-Link to board, power them. Connect board and PC through ethernet. Configure network interface with IP 192.168.0.100, mask 255.255.255.0, no gateway.
    3. Extract contents of demo example and follow instructions in "Project\FreeRTOS\udptcp_echo_server_netconn\readme.txt" for TrueSTUDIO (run truestudio, select workspace in "Project\FreeRTOS\udptcp_echo_server_netconn\TrueSTUDIO", import project and build it)
    4. After build go to debug configuration and modify predefined configuration "STM322xG_EVAL.elf": change JTAG Probe to "SEGGER J-Link", apply changes.
    5. Run debug. Try to ping 192.168.0.10, connect with putty to 192.168.0.10 on port 7 (raw connection) and send/receive echo. Everything works ok.

    Now reproduce my issue with little modifications of project. These modifications should not affect program and debugger behavior. I believe they conform ST's code architecture and conventions.
    6. Modify linker script stm32_flash.ld as follows:
    - add "MEMORY_B1_SRAM2 (xrw) : ORIGIN = 0x64000000, LENGTH = 2M" definition to MEMORY block;
    - locate .data and .bss output sections descriptions and change their regions to MEMORY_B1_SRAM2 (replace ">RAM" to ">MEMORY_B1_SRAM2")
    7. Modify "User\system_stm32f2xx.c": uncomment "#define DATA_IN_ExtSRAM"
    8. Modify "TrueSTUDIO\startup_stm32f2xx.s": locate line "bl SystemInit" and move it to blank line right after "Reset_Handler:" line.
    9. Additionally you can turn off compiler optimization (clear "-Os" option in "Other options" of Compiler settings in project properties). It increases the likelihood of issue (for me, at least).
    10. Rebuild and run debug. Be patient and wait for debug suspending with "<symbol is not available> 0x00000000" stop point.

    Additionally you could get a bonus bug ! Stable 1ms ping may become broken. It's hard to reproduce. I'm able to get it only after PC shutdown, j-link and board USB cables disconnect, PSU power off for a minute, PC start, connect j-link and board and immediately start debug. In a few first debug sessions I'm able to get ping failed after few seconds. If not, subsequent sessions will be stable and only chance is to start over again whole restart procedure.
  • Hi,

    We are not able to reproduce the problem here.

    Would it be able to strip down the project to a simpler one, so we can easily exclude application errors?
    Moreover, according to your last post, this problem is not reliably reproducible, even on your side:
    I'm still not sure but you can try to reproduce the issue with these steps (you may need a lot of patience to catch it):


    Please understand that there is not much we can do in this situation because without being able to reproduce a problem reliably,
    there is almost no indicator where to start analysis and how to check if the problem has really solved / how it is affected by changes,
    since you never know when it is usually going to appear again.

    What we need is a project as simple as possible that allows reliable reproduction of the problem, so we can analyze what is causing the problem and what can be done to fix it.


    Best regards
    Erik
    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.