CCS/CC3220SF: Adding Segger J-Link plug-in to CCS 9 : cannot see it anywhere; using J-link with CC3220SF

Hi,

When you are trying to connect, the small Segger Jlink icon shows up at the Windows taskbar. However, since you are using Linux, I don't think there is an easy way to get additional information - you would have to ask Segger about this.

Specifically to the target device itself, check if the board is properly powered, the JTAG jumpers are removed (thus isolating the built-in XDS110 debug probe) and the SOP jumpers match the configuration (JTAG or SWD modes). 

Keep in mind that support for CC322x devices is not very finished. The last discussions I recall did not have Flash or SPI Flash support implemented, but perhaps this may have changed. You can ask Segger about that as well.

Regards,

Rafael

desouza said:

 ...  You can ask Segger about that as well.  ...

Regards,

Rafael

Hi Rafael,

The problem is the log that Segger external binary (JLinkExe, or JLinkGDBServer) , or Jlink *dll/*.so should be writing or outputting on the console usually, is hidden somewhere by the CSS . I do not see this as for Segger support to help with, just observation.

Because, I can /could verify say, on the command line using just Segger commander, that I can connect to target, load binary, etc ..  All that wouldn't help me to find where the CCS redirects (if at all) the Segger messages.

For example, GNU ARM free plugin for Eclipse, creates/allocates a dedicated console window, where it channels JlinkGDBServer output. This you may find very useful for troubleshooting.  

As I understand, CCS may be using Jlink shared library to talk to the monitor and target, not a remote server. But anyhow, traces/log should be available somewhere.

I do not see such log available with CCS yet , and may be it is not available at all. 
If not available, that a pity. Can be said to be a big miss.

Really would need to request this to be available for those that use Segger JLink with CCS.

Hi,

Thanks for reporting back the outcome of your scenario. A few considerations:

- The advanced options that let you set the JTAG/SWD modes are fully controlled by Segger's interactions with our API.

- The "stdout" console output of Segger seems to be correctly redirected to the console view (the JLINKARM_* error message you saw).

- Further "stderr" debugging logs that could potentially delay the operation (albeit by a thin margin, but I don't know Segger's solution that well) could perhaps be turned on/off and redirected to a file (specified by the user) using added advanced options (controlled by Segger). 

All that is to say that we (TI) rely on them to highlight what is relevant to the user's experience with their tools - a similar approach is done with other third parties such as Spectrum Digital, Blackhawk, Seed, Wintech and others.

I can try to inform them of these changes but customer requests usually add more weight to this discussion.

Regards,

Rafael

Hi Rafael,

desouza said:

- Further "stderr" debugging logs that could potentially delay the operation (albeit by a thin margin, but I don't know Segger's solution that well) could perhaps be turned on/off and redirected to a file (specified by the user) using added advanced options (controlled by Segger). 

I do not see what that log could potentially delay, operation wise : it wouldn't delay the hardware monitor operation wrt to target, to my understanding. And that's the most important part. The operation of updating the log window /console in Eclipse shouldn't delay the other IDE threads either, can't easily see what , debugging wise, it would delay.

But, i don't know how CCS is structured, so just my guessing.  So thanks for feedback.