This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/MSP432P4111: Problems with Interrupt Analyzer

Part Number: MSP432P4111

Tool/software: Code Composer Studio

I have just set up my XDS200 debugger to help me analyze my firmware running on an MSP432P4111. I notice strange output from the Interrupt Analyzer tool:

Some of the interrupts seem to have the wrong names. For instance, UART2 is really DMA_INT1 for my system. After digging into this a little, it appears that my trace is somehow using the configuration from device_stellaris.xml instead of device_msp432.xml. After finding this path (ccs830/ccsv8/ti/ccs_base/emulation/analysis/xmldb/trace_config/devices), I was able to figure out what interrupts are being displayed. How can I specify that the correct file is used?

There are two other problems I have noticed. It appears that there are some period of time that are listed as "preempted" (red) for several interrupts, but nothing is running (green). I am not sure whether it is a display error or what to make of this. Also, I have set DMA_INT1 (seen here as UART2) at an interrupt priority higher than the other interrupts listed; however it still appears to be preempted according to this chart. Are these problems a result of using the wrong device file?

Thanks,

Mike Foss

  • My picture did not go through. Here is a screenshot that is referenced above:

  • Still having trouble uploading the picture...

  • After updating TI emupack, I see the correct interrupt names. However, I still see the problem of there being preemted (red) spaces with no running space displayed for some duration.I also see the problem where one interrupt seems to preempt another one even though the priority is set such that the first interrupt should not be preempted.

  • Michael Foss68 said:
    However, I still see the problem of there being preemted (red) spaces with no running space displayed for some duration.I also see the problem where one interrupt seems to preempt another one even though the priority is set such that the first interrupt should not be preempted.

    If you look in the "Trace Viewer - CORTEX_M4_0" tab at the Trace Status column are there any instances of "OVERFLOW!" reported?

    A Trace Status of "OVERFLOW!" means the bandwidth of the SWO link was overloaded and some sample(s) have been lost.

  • Yes, I do see some of those messages. How can I avoid the overflow condition?

  • Michael Foss68 said:
    How can I avoid the overflow condition?

    See the Troubleshooting section on the SWO Trace Wiki page:

    - Part 1 describes how to reduce the timestamp resolution.

    - Part 3 describes how to manually set the SWO baud rate; although CCS is supposed to already set the maximum baud rate.

    Also, what CPU frequency is the MSP432P4111 running at? This is because the SWO baud rate is divided from the CPU clock frequency.

  • I set the resolution to 64, but I still see periodic "Receive an event as DWT_EXCCNT overflow Occured" messages. I have been setting the SWO baud rate to auto and the UART to 48MHz to match my CPU frequency. Should I set the SWO baud rate manually?

    Thank you for your help!

  • Michael Foss68 said:
    I have been setting the SWO baud rate to auto and the UART to 48MHz to match my CPU frequency. Should I set the SWO baud rate manually?

    You can set the SWO baud rate manually, by setting the SWO Prescaler manually. However, the upper limit of the the allowable SWO baud rate depends upon the device and emulator.

    I can't find it documented what the maximum SWO baud rate of a XDS200 or XDS110 is, but by enabling Trace Logging and looking at the trace output you can see what the baud rate has been set to.

    In a test with a MSP432P401R running a program with its CPU clock frequency set to 48 MHz, connected to a XDS110 with CCS 9.1 running under Windows 10 and Interrupt Profiling started with the Prescaler set to Auto the trace output showed the SWO baud rate was set to 12 Mbaud with a prescaler of 3 selected:

        E 19:42:36:190 | SwoRcvr_UARTCollector: Original emulator Baud rate = 115200
        E 19:42:36:190 | SwoRcvr_UARTCollector: Auto Prescalar is = 3
        E 19:42:36:190 | SwoRcvr_UARTCollector: UART configuration: Target: Trace Clock = 48000000.000000, Baud rate=12000000, Prescalar=3
        E 19:42:36:190 | SwoRcvr_UARTCollector: UART configuration: Emulator: Baud rate=12000000

    As per Asynchronous Clock Prescaler Register, TPIU_ACPR the actual divisor is the prescaler value + 1.

    With this configuration I tried to manually set the prescaler to the next smaller value of 2. However, that resulted in garbage output from the Interrupt Profiling  The trace output showed that while the SWO baud rate had been calculated as 16 Mbaud, the XDS110 UART was clamped at 15 Mbaud which based upon previous tests with the XDS110 is the maximum supported baud rate (under Windows):

        E 19:47:12:682 | SwoRcvr_UARTCollector: Original emulator Baud rate = 115200
        E 19:47:12:682 | SwoRcvr_UARTCollector: UART configuration: Target: Trace Clock = 48000000.000000, Baud rate=16000000, Prescalar=2
        E 19:47:12:682 | SwoRcvr_UARTCollector: UART configuration: Emulator: Baud rate=15000000

    So, yes you can try and set the SWO baud rate but if set to high then the hardware trace analyser output will be garbage. Some notes:

    1. I don't have a standalone XDS200 to be able to investigate what the maximum allowed SWO baud rate is.

    2. In previous tests with a XDS110 found that the maximum supported SWO baud rate was 15 Mbaud under Windows 10, yet was only 4 Mbaud under Linux - see 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). Not sure if a similar issue occurs with a XDS200.

    3. The thread referenced above also found the XDS200 has worse throughput for SWO trace than the XDS110.

    4. I attempted to repeat a test on CCS 9.1 (and CCS 8.3) under Linux to see what the SWO baud rate in the XDS110 was set to; but the act of enabling trace logging causes CCS to crash - see CCS/MSP432P401R: CCS 9.1.0.00010 under Linux crashes when TI_TRACE_LOGGING=6 set to enable trace logging

  • Thank you for your detailed information above--it was helpful!

    Indeed I am running under Linux (within a virtual machine, even). So I suspect that my USB performance is not optimal. I also saw the Code Composer crash after setting the TI_TRACE_LOGGING environment variable to 6.

    That said, I was able to adjust the SWO prescalar to 11, which gave me a baud rate of 4Mbaud (48MHz / (11 + 1)). This setting was about the lowest prescalar that I could hit before seeing outright trace failures. It's not quite enough to keep up with my interrupt rate since I'm trying to examine what happens on a UART ISR receiving at 1Mbaud. However, now that I know the SWO buffer is 5 entries deep, I was able to look at the ISR runtime of the first five bytes received. Since there is not much branching in this ISR, I can just look at these 5 entries to gauge my ISR runtime.

    I will try to order an XDS110 to see if that one can keep up better. I just assumed that the XDS200 would be better for me because of the higher number. :-)

    Thank you again!

  • In case you hadn't seen it, I also created the thread CCS/MSP432P401R: CCS 9.1 Interrupt Analyzer view doesn't indicate when captured data has been affected by data loss due to SWO overflow to request an enhancement to the Interrupt Analyzer to warn if SWO overflow has occurred.