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.