SWD/SWO Trace for CC2650 with XDS200 & IAR

Are there any plans to make this available in IAR?

Unfortunately i am unable to get CCS to work: e2e.ti.com/.../411889

I have been trying to get this to work in CCS but no luck. 

I am using CCS6.1 and XDS200 connected to a SensorTag via 10pin header. 

I created a new target configuration selecting CC2650 and XDS200 and selected SWD/Trace. The error iam getting from CCS is below. I can program and otherwise communicate with the target in 2 and 4 pin mode without any problems.

An error occurred while hard opening the controller.

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-615' (0xfffffd99).
The title is 'SC_ERR_SWD_PROTOCOL'.

The explanation is:
The target failed to see a correctly formatted SWD header. The 
connection to the target may be unreliable. Try lowering the 
TCLK setting before trying again.

I have tried the SensorTag with 50 and 40, same result. Also our board uses 40 and i get the same result, regardless of 40/50 selection.

Can you confirm that you are able to SWD/Trace from XDS200 to SensorTag and if so, can you post a screenshot of the target configuration settings?

Thanks.

Hi, thanks for looking into this. 

We didn't know I-Jet works with CC26xx and bought a XDS200 specifically for that. How does J-Jet speed compare to XDS200? Does I-Jet work from CCS?

Hi,

Do you have an update on this? Or is there another way to enable trace with CCS? Also, we have XDS100v3 emulators - it looks to me like trace wouldn't work with them; we would need at least XDS200. Is that true?

Hi,

Sorry for not getting back to you. I've not received a timeline yet, but I'm pushing to get an answer. 

XDS100v3 emulators do not support trace, I believe you need the XDS200 (or XDS110). The XDS110 does not support trace together with cJTAG at the moment, so XDS200 is the recommended option.

Br,
TIABO

CC2650: You can pretty much output SWO trace to any pin.

In 2-pin cJTAG mode, I believe the emulators will expect SWO trace on the TDO pin.

Snippet for configuring CC2650:

#define ITM_Port32(n) (*((volatile unsigned int *)(0xE0000000+4*n))) 

// Map SWV to DIO_25 (can be any IO)
IOCPortConfigureSet(IOID_25, IOC_PORT_MCU_SWV, IOC_STD_OUTPUT); 

// Make sure data has been clocked out before sending 
while(ITM_Port32(1) == 0x00); 
ITM_Port32(1) = 42; 

OK, thanks. So it seems that would be a way to allow software generated trace data to be output on SWO. But what I'm really looking for is a way to trace all instructions executed and possibly data accesses via a hardware trace mechanism like ETM. This is useful, for example, for debugging exceptions and you want to see what instructions were executed leading up to the exception. Is there a way to enable that?

Hi,

I assume you mean CC2650, not CC2540.

CC2650 is not SWD enabled, so using CC2650  in Serial Wire Debug (SWD) will never work.

XDS200 support for 2-pin cJTAG + SWO trace will be included in the next XDS emulation driver bundle. The last information I have is that it is expected around October November (updated 2015-09-17).

Br,
TIABO

Off the top of my head, 2-pin cJTAG occupies less I/O on the CC26xx than 4-pin JTAG. CC26xx powers up in 2-pin mode and a switching sequence must be done by the emulators to enable TDO and TDI pins.

2-pin cJTAG time-multiplexes TMS, TDO and TDI signals, so the throughput may be somewhat lower than 4-pin JTAG. There are however optimized scan formats that minimizes this difference.

The XDS200 emulator has a higher data throughput, so the time it takes to program the device flash is less than for example XDS100v3.
XDS110 has a performance in terms of throughput somewhere between XDS100v3 and XDS200. XDS110 and XDS200 hardware is SWO trace enabled (support in the driver stack to come).

Br,
TIABO

Hi,

Today, the IAR I-Jet supports SWO trace in IAR with CC13xx/CC26xx.

Br,
TIABO

Hi,

The easiest way to just get some printf in IAR is also the worst way.. You can use semi-hosted i/o which uses the debugger to read out memory and print it in the terminal window.

The reason it's not so ideal is that it will break execution for a while while performing the printf. To enable this, go to your project options -> General Options -> Library Configuration -> Library low-level interface implementation -> Semihosted -> stdout -> via semihosting.

You can in the Library Options choose to use 'buffered terminal output' which is probably less intrusive than the alternative, but I don't have any timing numbers.

To use this later, you include stdio.h and use printf(..) as you normally would. The output is then in View->Terminal I/O.

A slightly better approach is to use the UART to print out. See  on our wiki for details.

Best regards,
Aslak

Aslak N. said:

...printf in IAR is also the worst way.. 

Thanks for your details on how to get printf working.

Is there a way to do "printf-like" debugging that does not break execution?