CCS/MSP-EXP432E401Y: Statistical Function Profiling using a XDS110 causes CCS to hang if try any select a Sampling Interval of 832 cycles (or lower)

desouza said:

I can't necessarily reproduce the exact same problems on CCSv8.0.0 with the same TI Emulators package, but certainly the lower Sampling Interval influences the stability of the JTAG connection and (perhaps) the integrity of the device

Having run CCS 8.0.0.00016 and TI Emulators 7.0.188.0 under Ubuntu 16.04 using the same project, board and PC (dual boots either Windows or Ubuntu) I see different behaviour under Ubuntu. In that with CCS under Ubuntu:

a) When use the default Sampling Interval of 1024 cycles in Ubuntu get OVERFLOW! reported as the Trace Status and the Time (ticks) column is not incrementing:

Whereas under Windows 10 with a Sampling Interval of 1024 cycle didn't get the OVERFLOW! 

b) With a Sampling Interval of 832 cycles or less under Ubuntu CCS doesn't become unresponsive, but the trace data is incomplete due to the "OVERFLOW!". Whereas under Windows 10 CCS became unresponsive.

c) Under Ubtunu to get the trace OVERFLOW! to disappear have to increase the Sampling Interval to 2048 cycles.

In the Statistical Function Profiling configuration the Clock Frequency is being manually set to 120 MHz. Under Windows 10 the SWO baud rate is being set to 15 Mbaud (as shown in the Trace logging):

    E 22:51:59:672 | SwoRcvr_UARTCollector: Original emulator Baud rate = 115190
    E 22:51:59:682 | SwoRcvr_UARTCollector: Auto Prescalar is = 7
    E 22:51:59:682 | SwoRcvr_UARTCollector: UART configuration: Target: Trace Clock = 120000000.000000, Baud rate=15000000, Prescalar=7
    E 22:51:59:682 | SwoRcvr_UARTCollector: UART configuration: Emulator: Baud rate=15000000

Whereas under Ubuntu the SWO baud rate is being set to 4 Mbaud:

    E 18:22:12:294 | SwoRcvr_UARTCollector: COM port /dev/ttyACM1 opened with port handle = 260
    E 18:22:12:294 | SwoRcvr_UARTCollector: Original emulator Baud rate = 4098, Rate = 115200
    E 18:22:12:294 | SwoRcvr_UARTCollector: Comm state is set
M     18:22:12:294 | SwoRcvr_UARTCollector: Auto Prescalar is = 29
    E 18:22:12:294 | SwoRcvr_UARTCollector: UART configuration: Target: Trace Clock = 120000000.000000, Baud rate=4000000, Prescalar=29
    E 18:22:12:294 | SwoRcvr_UARTCollector: UART configuration: Emulator: Baud code=4111, Baud rate=4000000

Is it a bug that under Linux the SWO baud rate is set to a lower value for the XDS110 than under Windows, or a limitation of the driver under Linux?

desouza said:

I can't necessarily reproduce the exact same problems on CCSv8.0.0 with the same TI Emulators package, but certainly the lower Sampling Interval influences the stability of the JTAG connection and (perhaps) the integrity of the device

a) With the 15 Mbaud SWO set under Windows a sample interval of 448 cycles should have sufficient bandwidth to output PC Samples, but the next lowest sample interval of 384 cycles will have insufficient bandwidth (resulting in an OVERFLOW!). I.e. when CCS under Windows became unresponsive when attempted to use an sample interval of 832 cycles there should have been sufficient bandwidth to output all the PC Samples on the SWO UART.

b) With the 4 Mbaud SWO set under Ubuntu a sample interval of a sample interval of 2048 has sufficient bandwidth to output PC Samples, but the next lowest sample interval of 1024 cycles has insufficient bandwidth. That explains why under Ubuntu had to increase the sample interval to 2048 cycles to avoid the OVERFLOW!

Chester,

>> Is it a bug that under Linux the SWO baud rate is set to a lower value for the XDS110 than under Windows, or a limitation of the driver under Linux?

In my experience the Linux device drivers tend to be slower than its Windows counterparts, which would explain the extra time required to a clean SWO sample data collection.

The analysis of the Data throughput makes sense and therefore I start to suspect of the following additional factors: either insufficient sync packets, which may skew the data collection; any unknown (at least to me) protocol eating some of the available bandwidth; and obviously the possible bug/performance issue in the drivers themselves.

With all this in mind, I filed today the bug number DBGTRC-3897 (it will be publicly available later today). I will also double-check the performance issue in Linux.

Since we are at it, I filed an enhancement to address an annoyance where the Advanced Settings do not "stick" if you switch between Trace elements. (DBGTRC-3899)

I apologize for the inconvenience,
Rafael

desouza said:

With all this in mind, I filed today the bug number DBGTRC-3897 (it will be publicly available later today).

I am curious if a XDS200 is better or worse than the XDS110 than collecting the SWO trace at a high rate. Since I don't have a XDS200 to try it myself, can you test what happens with a XDS200 when the Statistical Function Profiling Sampling Interval is reduced?

For reference, I was trying to lower the Sampling Interval for debugging the issue in MSP432E401Y: If FreeRTOS context switch occurs during a flash programming operation processor can crash, since after the crash the debugger is unable to halt the device.