Other Parts Discussed in Thread: MSP-EXP432E401Y
TM4C1294NCPDT: TM4C1294NCPDT flash write issue is a problem I have been investigating on a TM4C129 device. Since the MSP432E devices appear to be based upon the TM4C129 devices, created an equivalent test program which runs on MSP-EXP432E401Y built using:
- TI ARM compiler v18.1.1.LTS
- simplelink_msp432e4_sdk_2_10_00_17
- FreeRTOSv10.0.1
This program has two FreeRTOS theads:
a) ledThread() which flashes LED0 at 1Hz.
b) flashWriteThread() which erases and programs the upper flash bank, while the program runs in the lower flash bank. The ROM based flashErase() and flashProgram() functions are used.
When the program is run there is a prompt on the UART about if to set or clear the FPFOFF Force Prefetch Off bit in the FLASHCONF Register, and the test then erases and programs sectors in the upper flash bank.
If the test is run with the FPFOFF bit clear it crashes as indicating by the output on UART stopping and the LED no longer flashes:
Flash Failure Test Press 0 (with FPFOFF clear) or 1 (with FPFOFF set) to start the flash test >0 Clearing FPFOFF erasing sector 36 writing flash line at 00090000
Once the program has crashed the debugger can't halt the processor, resulting in the following error if attempt to Suspend execution:
CORTEX_M4_0: Trouble Halting Target CPU: (Error -2062 @ 0x0) Unable to halt device. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 7.0.188.0)
Once the program has crashed, have to press the reset button on the MSP-EXP432E401Y for the debugger to be able to connect to the processor again.
Whereas if run the test with the FPOFF bit set it runs to completion:
Flash Failure Test Press 0 (with FPFOFF clear) or 1 (with FPFOFF set) to start the flash test >1 Setting FPFOFF erasing sector 36 writing flash line at 00090000 erasing sector 37 writing flash line at 00094000 erasing sector 38 writing flash line at 00098000 erasing sector 39 writing flash line at 0009C000 erasing sector 40 writing flash line at 000A0000 erasing sector 41 writing flash line at 000A4000 erasing sector 42 writing flash line at 000A8000 erasing sector 43 writing flash line at 000AC000 erasing sector 44 writing flash line at 000B0000 erasing sector 45 writing flash line at 000B4000 erasing sector 46 writing flash line at 000B8000 erasing sector 47 writing flash line at 000BC000 erasing sector 48 writing flash line at 000C0000 erasing sector 49 writing flash line at 000C4000 erasing sector 50 writing flash line at 000C8000 erasing sector 51 writing flash line at 000CC000 erasing sector 52 writing flash line at 000D0000 erasing sector 53 writing flash line at 000D4000 erasing sector 54 writing flash line at 000D8000 erasing sector 55 writing flash line at 000DC000 erasing sector 56 writing flash line at 000E0000 erasing sector 57 writing flash line at 000E4000 erasing sector 58 writing flash line at 000E8000 erasing sector 59 writing flash line at 000EC000 erasing sector 60 writing flash line at 000F0000 erasing sector 61 writing flash line at 000F4000 erasing sector 62 writing flash line at 000F8000 erasing sector 63 writing flash line at 000FC000 Finished.
The processor crash seems sensitive to the relative offset of the instructions in the FreeRTOS xPortPendSVHandler assembler function w.r.t. the flash prefetch buffer boundaries. To control this there is the following in the MSP_EXP432E401Y_FREERTOS.cmd linker command file:
/* Place the code from portasm.obj which contains the FreeRTOS context switching assembler routines
in a section with 32-byte alignment, which is one MSP432E4 flash prefetch buffer, and with an optional gap.
This allows the instructions in xPortPendSVHandler to be adjusted relative to the flash prefetch buffer boundaries
as this can make the program run or crash.
As of compiling this program with the TI ARM v18.1.1.LTS compiler and FreeRTOSv10.0.1 a gap of 4 or 8 bytes
can cause the program to crash when the flash prefetch buffer is enabled. */
aligned: > FLASH, align(32)
{
.+= 4; /* Insert a gap to shift the instructions in portasm.obj relative to a flash prefetch boundary.
The gap must be a multiple of 4 bytes due to the .align 4 directives in freertos/portable/CCS/ARM_CM4F/portasm.asm */
freertos_builds_MSP_EXP432E401Y_release_ccs.lib<portasm.obj>(.text)
}
When the gap is 4 or 8 bytes the program crashes when the FPFOFF bit is clear.
Whereas if the gap is 0, 12, 16, 20, 24 or 28 bytes the program no longer crashes when the FPFOFF bit is clear.
After the crash the debugger is locked out of the processor, so can't directly post mortem. However, by using Statistical Function Profiling found that the sequence around a crash is:
a) The program is in a call to ROM_flashProgram()
b) There are a couple of PC samples in FreeRTOS context switching (the LED flashing task is woken up at regular intervals)
c) All remaining PC samples are the same address, which is the "bx lr" instruction at the end of the xPortPendSVHandler() function.
Is the cause of the crash a device errata w.r.t. the flash prefetch buffers?
The test program is attached FlashTestFailure_MSP_EXP432E401Y_freertos_ccs.zip
