• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 780 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/EK-TM4C1294XL: J-Link Halts on Service Call

Bryce Hillam
Prodigy 60 points
Part Number: EK-TM4C1294XL
Other Parts Discussed in Thread: SEGGER

Tool/software: Code Composer Studio

I am trying to use a Segger J-Link to debug FreeRTOS-based application on an EK-TM4C1294XL evaluation kit.

When I attempt to debug the target within Code Composer Studio, the code runs to main and can be single-stepped on-demand, however upon calling startup of the FreeRTOS scheduler, service handler 0 is called (line 151 of portasm.s) and execution is halted. Attempts to step past this instruction simply result in the debugger remaining paused at the same instruction.
I am aware that semihosting also makes use of service calls and have disabled this feature since it is not needed in my target application. Despite this, I still cannot continue beyond startup of the FreeRTOS scheduler. I can debug the application without any problems if I connect to the target after it has been reset.

I found a forum post and a blog where the same problem was fixed in gdb by adding monitor reset 0 to the debugger startup options, but I do not see anywhere to set this option within CCS. Presumably CCS is passing on some undesired setting to ccs_base\DebugServer\drivers\JLinkARM.dll (as far as I can tell, this is what interfaces to the debugger) which causes this problem.

I've already asked for support from Segger and they do not believe this to be any issue related to their own hardware or the debugger support packages installed in CCS. What am I missing?

  • 0
    TI__Guru**** 171104 points
    Hi,

    I don't use FreeRTOS much, but I recall using Jlink with FreeRTOS on a different architecture (MSP432) and did not have these issues.

    I can try to reproduce this tomorrow, but is there any specific example code you are running that is causing this?

    Regarding the monitor reset 0, CCS has multiple resets that can be accessed via the menu Run --> Reset - perhaps one of the options can help you?

    Hope this helps,
    Rafael
  • 0 in reply to desouza
    Prodigy 60 points

    Thanks for your advice Rafael.

    desouza said:
    Regarding the monitor reset 0, CCS has multiple resets that can be accessed via the menu Run --> Reset - perhaps one of the options can help you?

    All four of CPU reset, core reset, system reset, and board reset, cause execution to jump to ResetISR and is caught by the debugger. Code runs normally after continuing from this point, i.e. this seems to be a workaround. My breakpoints work normally after this has been done.

    This also appears to confirm the possibility that the reset behaviour used by the JLink is not quite right for my target.