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 6.1.1 Statistical Function Profiling problem with MSP432 and XDS110

Other Parts Discussed in Thread: MSPWARE, BOOSTXL-K350QVG-S1

Using CCS 6.1.1.00022 under Linux was attempting to use Statistical Function Profiling on a MSP-EXP432P401R, i.e. using the XDS110 on-board emulator set to "Use SWD Mode with SWO Trace enabled" to access the MSP432P401R device. Problems have been seen with both the CORTEX_M4F_MSP432_LaunchPad_IAR_CCS_Keil demo from FreeRTOS V8.2.3 and the BOOSTXL-K350QVG-S1_GrlibExample_MSP432P401R example from MSPware.

The problems are:

1) When main was reached, started Statistical Function Profiling with the default options. After the target was suspended the trace had terminated early with the error "Bad trace data packet sequence". An example from the FreeRTOS demo:

The last trace was from the PCM_setCoreVoltageLevelWithTimeout() function called from PCM_setCoreVoltageLevel() called from the following function:

static void prvConfigureClocks( void )
{
	/* The full demo configures the clocks for maximum frequency, wheras the
	blinky demo uses a slower clock as it also uses low power features.  Maximum
	freqency also needs more voltage.

	From the datashee:  For AM_LDO_VCORE1 and AM_DCDC_VCORE1 modes, the maximum
	CPU operating frequency is 48 MHz and maximum input clock frequency for
	peripherals is 24 MHz. */
	PCM_setCoreVoltageLevel( PCM_VCORE1 );
	CS_setDCOCenteredFrequency( CS_DCO_FREQUENCY_48 );
	CS_initClockSignal( CS_HSMCLK, CS_DCOCLK_SELECT, CS_CLOCK_DIVIDER_1 );
	CS_initClockSignal( CS_SMCLK, CS_DCOCLK_SELECT, CS_CLOCK_DIVIDER_1 );
	CS_initClockSignal( CS_MCLK, CS_DCOCLK_SELECT, CS_CLOCK_DIVIDER_1 );
	CS_initClockSignal( CS_ACLK, CS_REFOCLK_SELECT, CS_CLOCK_DIVIDER_1 );
}

I think the issue is that when the clock frequency is changed, the SWO trace gets an invalid packet. Not sure if this is a bug, or a limitation of the SWO trace not being able to be maintained across changes to the core clock frequency.

2) Because of the above, the Statistical Function Profiling was only started after the clock frequency had been set. However, when the target was suspended CCS crashed. A set of crash dump files is attached ccs_crash.zip

The following from the hs_err_7731.log shows the crash appears to be in the Ti::Sds::Trace::CItmDecoderRouter::RouterOutputStatusMessage function, which looks to be the trace decoder:

# JRE version: Java(TM) SE Runtime Environment (7.0_60-b19) (build 1.7.0_60-b19)
# Java VM: Java HotSpot(TM) Client VM (24.60-b09 mixed mode linux-x86 )
# Problematic frame:
# C  [libItmDecoder.so+0x134cb]  Ti::Sds::Trace::CItmDecoderRouter::RouterOutputStatusMessage(TraceStatus, unsigned int, unsigned char*, unsigned int*)+0x6b

These two problems are repeatable.

  • Chester Gillon said:
    2) Because of the above, the Statistical Function Profiling was only started after the clock frequency had been set. However, when the target was suspended CCS crashed.

    An update to TI Emulators 6.0.83.0 has prevented the CCS crash when the target is halted with Statistical Function Profiling via SWO trace enabled.

    The release notes for TI Emulators 6.0.83.0 mentions "Various bug fixes for SWO trace".

    Following the update, the first issue still exists, in that the SWO trace stops when the CPU core frequency is changed.

  • Chester,

    Chester Gillon said:
    I think the issue is that when the clock frequency is changed, the SWO trace gets an invalid packet. Not sure if this is a bug, or a limitation of the SWO trace not being able to be maintained across changes to the core clock frequency.

    The SWO clock is dependent on the device frequency. Last time I checked it was not possible to automatically determine the running clock of MSP432 devices (TM4C devices this is fine). In the light of the issues you are having, perhaps this is still the case.

    Can you try to manually change the clock speed of the UART settings? During trace setup, click on the Advanced button and then select the following settings on the tree:

    Hope this helps,

    Rafael 

  • desouza said:
    The SWO clock is dependent on the device frequency. Last time I checked it was not possible to automatically determine the running clock of MSP432 devices (TM4C devices this is fine). In the light of the issues you are having, perhaps this is still the case.

    Thanks for the explanation.

    desouza said:
    Can you try to manually change the clock speed of the UART settings?

    I repeated the test with the UART clock speed to manual at 48MHz. Statistical Function Profiling was started when the program was at the start of main, when the core clock frequency is lower, the program was free run and later halted. With the UART clock speed set to manual at 48MHz the SWO trace showed:
    - No trace prior to the core clock frequency being set to 48MHz, i.e. when running at the reset value of the core clock frequency.
    - Sometime one corrupt initial trace entry after the core clock frequency had been changed to 48MHz.
    - The remaining trace entries while the core clock frequency was running at 48MHz.

    This is usable, since was looking at getting Statistical Function Profiling to capture history prior to a run time failure.