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

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 :
SVC is used by FreeRTOS, and it shouldn't cause J-Link to get stuck on this .. ?

The issue was also seems reported here , in 2018:
forum.segger.com/index.php/Thr…rtFirstTask/?postID=20991

Abandoned, not sure there was solution ...

Hello Nino,


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.

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.

Please see the JLinkLog , with app binary, attached. The log ends when it (debugging) stucks on svc 0

bump ...

Some news would be good.

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 )

Ping .... any reply Segger?

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.

I think this arch drawing helps explain why SWD /2-wire seems to work but not JTAG 4-wire ..

I've seen at least few posts on Segger forum about problems with this IcePick. May be this was resolved somewhere already?

Hello Fabian,



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


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.



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.

Note: TI forum support confirmed the reported issue as per thread: thus they 've confirmed the issue independently.

But I don't think they can do anything about it : as this is Segger specific.

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)

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.