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.
    • Hi,
      We just tried to have a look at this.
      Unfortunately we were not able to get the application you sent us to work.
      We always get stuck in the boot loader at address 0x000029B8.

      We were using the TI CC3220 LaunchPad (wiki.segger.com/CC3220_LaunchPad).

      Are you using the same board?
      Could you sent us an application, the issue you mentioned here is reproducible with on the TI CC3220 LaunchPad?

      Best regards,
      Fabian Federschmidt
      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 Fabian,


      SEGGER - Fabian wrote:

      We were using the TI CC3220 LaunchPad (wiki.segger.com/CC3220_LaunchPad).

      No, technically it is CC3220SF, not CC3220. I believe difference is external serial flash - please double check.


      SEGGER - Fabian wrote:

      Are you using the same board?

      Could you sent us an application, the issue you mentioned here is reproducible with on the TI CC3220 LaunchPad?
      I do not have non SF, only SF board . And I'm not even sure there is just CC3220.

      The application may work on your chip, because the binary is not linked to download or run from external flash.


      SEGGER - Fabian wrote:

      We always get stuck in the boot loader at address 0x000029B8.

      Easiest to try first re-store the system to default pre-configured production app / image (if CC3220 board comes with it; my C3220SF does.) . It puts default app, which should run after re-set, before you try to program with J-Link your binary. Refer to board guide - sw2 + Reset I think.. .Plus allow time for re-programming ... (a min or so).

      If you do not restore it, you may encounter the issue as you reported : pc at 000029B8. I see that my CF board can show the same behavior / address you found. You will have no -luck then using J-Link the usual way.

      EDIT: I looked at your link , and you have MISMATCH between your link / board name header / article, and the picture shown : on the photo, the board has tag CC3220SF , not per your title. Please fix.

      So the board is correct.

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

    • SEGGER - Fabian wrote:



      We always get stuck in the boot loader at address 0x000029B8.

      Can I ask you, how did you manage to get the bootloader/ROM code stuck at that address? I tried many things, changing jumper settings, etc.. I seems cannot get it purposefully stuck at that address, and the only time I had it myself, I cannot replicate it now.

      Could you share your exact board config - jumper settings / positions (not just SOP ones) , power supply options, etc. By observation, system behaves 'best' when bootloader is stuck at that place , I actually Want it now: I cannot confirm this (i.e. , = do NOt close this issue), but from one (just one!) unconfirmed test I did with the app I provided you, if the bootloader does get stuck at the address as you caught it, then, uploading & running the app through jtag config did not show me, in my only one test, the svc0 issue. As this chip's bootloader enables and controls jtag access there can be a config issue.

      About restoring the board & chip to default manufactured or sold state: you may need to use UniFlash tool to restore this. Alternatively, you can build the TI's provided AT command server example in the SDK, and restore the system to manufactured state using AT command - see guide. (and yes, it does work when the bootloader get stuck at that address)
    • New

      SEGGER - Fabian wrote:

      ..
      We always get stuck in the boot loader at address 0x000029B8.....

      Best regards,
      Fabian Federschmidt

      Hi Fabian.

      I now got your case, and I have the steps for you to replicate the issue.

      Please start by examining the thread I created here - forum.segger.com/index.php/Thr…p-binary-for-TI-CC3220SF/
      Change the how-to step 1 to use jtag (and check your board is set for 4-wire/jtag debug)

      Load & run the binary as per how-to. The app /binary should run normally under Segger monitor, with no Svc0 issue. (you should see a trace on serial / uart)

      Now make the app persistent / prevent ROM code from wiping it, by writing the magic header as per how to. Restart / reset the board.

      Now, the app should be auto-loaded / started automatically by the bootloader. Next, if you start the app as per the how-to, in this case you should get suck in svc0 call in the app code - FreeRTOS will not start, app will be blocked. In JTAG config only. In SWD mode, J-link / Segger will not have this issue.

      To revert to bootrom not starting the app (but also wiping out internal serial flash every time ... )
      w4 0x01000000 0x5AA5A55A 0xffffffff

      and reset the board. Now you can do clean JTAG again as described above.