TI CC3220SF , CM4, J-Link , FreeRTOS : cannot continue/stuck at SVC 0 at prvPortStartFirstTask ..

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

    • TI CC3220SF , CM4, J-Link , FreeRTOS : cannot continue/stuck at SVC 0 at prvPortStartFirstTask ..

      On the CC3220SF launch board, I do a simple hello world uart sample, based on FreeRTOS. The code loads and starts, but, when FreeRTOS tries to start first task, the J-Link/GDBServer halts it seems in debug request on call to prvPortStartFirstTask.
      And it doesnt get out of it, code cannot resume.

      snippet of what SeggerGDBServer prints:
      Starting target CPU...
      ...Target halted (DBGRQ, PC = 0x01004EB2)
      ---------------------------

      snippet from GDB client:
      Program received signal SIGTRAP, Trace/breakpoint trap.
      0x01004eb2 in prvPortStartFirstTask () at FreeRTOS/Source/portable/GCC/ARM_CM3/port.c:239
      239__asm volatile(
      ---------------------------

      And if I continue , it just hits constantly that same SIGTRAP and not going further. This I experience with my J-Link (EDU) , J-Link software JLink_V652c. EDIT: tried latest too - V6.52e,

      Interestingly, running the exactly same code/binary through the on-board emulator from TI, XDS110, I do not get this behaviour .. So this is J-Link specific.
      (I can't recall seeing this problem using same FreeRTOS base code but on another board and chip, using another J-Link probe and J-Link software though ..)

      The problem seems been observed years back, but , it was supposedly fixed ? see thread below .
      Any suggestion what's going on for me?

      sigtrap problem from old Segger thread 2015

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

    • It is that SVC issue.

      Here is me trying to step in JLinkExe:

      J-Link>s
      01004E98: 00 DF SVC #0
      J-Link>s
      01004E98: 00 DF SVC #0
      J-Link>s
      01004E98: 00 DF SVC #0
      .............

      Here is that call disassembly :

      C Source Code

      1. prvPortStartFirstTask
      2. 0x01004E84: LDR r0,[pc,#20] ; [0x1004E9C] = 0xE000ED08
      3. 0x01004E86: LDR r0,[r0,#0]
      4. 0x01004E88: LDR r0,[r0,#0]
      5. 0x01004E8A: MSR MSP,r0
      6. 0x01004E8E: CPSIE i
      7. 0x01004E90: DSB
      8. 0x01004E94: ISB
      9. 0x01004E98: SVC #0x0
      10. 0x01004E9A: NOP
      11. 0x01004E9C: DCD 0xE000ED08
      Display All
      SVC is used by FreeRTOS, and it shouldn't cause J-Link to get stuck on this .. ?
    • Hello,

      Thank you for your inquiry.
      The other thread was abandoned due to inactivity of the OP.

      So far issues regarding GDBServer and SVC were not reproducible or the solution was outside of our softwarere.
      Nonetheless if you can provide us with a reproducer that works out-of-the-box on an eval board we could take a look.
      Could you provide a J-Link log of a failing session? wiki.segger.com/Enable_J-Link_log_file
      Does the issue appear when using Ozone instead? segger.com/products/development-tools/ozone-j-link-debugger/

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


      SEGGER - Nino wrote:

      Hello,

      Nonetheless if you can provide us with a reproducer that works out-of-the-box on an eval board we could take a look.
      I should be able to. The board is the eval CC3220SF-LAUNCHPAD ( easy to get for you), and the code is all standard from TI's example base.

      SEGGER - Nino wrote:

      Does the issue appear when using Ozone instead? segger.com/products/development-tools/ozone-j-link-debugger/

      Could you Please explain why Ozone , vs me already have reproduced it with just JLinkExe (see above) , is different? Wouldn't Ozone just use the JLink DLL/*.so from JLink?

      I will be reporting what you asked.

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

    • This is weird ..

      I'm testing now, and, if I switch the board to SWD (using on-board SOP jumpers configuration from JTAG (which I prefer still) to SWD), then , based on test I did now, J-Link does not have that SVC 0 issue anymore ..

      Could Segger look at it please .. ? I obviously don't know how that relates, and why on-board XDS emulator has no such issue, but re-tried couple of times, it doesn't have same issue when in SWD.

      It feels quite sluggish though, when hitting breakpoint.

      ( I don't think SWD is optimal for my app, speed wise )

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

    • Hello,

      This is still *not* at support forum! Please familiarize yourself with the forum rules before posting. Bumping threads will only slow down our answering process as threads with oldest activity will be answered first. So you are really not helping yourself here.

      If you have a valid support request and are in support period with the affected SEGGER product feel free to open a support request via our official support channels.
      You can find all needed information in my signature. If your products are not in support period you have to wait for our engineers to find time between their paid projects just like everyone else.

      Best regards,
      Nino
      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.
    • SEGGER - Nino wrote:

      Bumping threads will only slow down our answering process as threads with oldest activity
      Oh ok, I did not know honestly.

      I can also openly say that, although I have J-Trace module (purchased directly from Segger, but haven't used any support for it) , I actually using J-Link Edu for this specific problem.
      J-Link EDU, as I think, that product has no official Segger support whatsoever, as I understand it.
      So you may ignore the issue I suppose ... (Although it persists not just on Edu, but on the J-Trace too).

      But, I will just hope & wait that , this issue will get some feedback .. I mean, it's been technically open for a couple of years or so, and didnt' go any further/ closed as ABANDONED at least once ....

      So I'll just wait & hope.

      Thanks again.