Hello there!
We have a odd error in the bootloader on some of our Systems. We send a FW-File over the USART to the bootloader and the download progress is displayed on the LCD. But on some of our systems the bootloader crashes and resets as soon as the LCD is updated. Up to now we have only devices where it is always working or always failing, we haven't found a device where it is sometimes crashing. All the devices are technically identical without any differences in the hardware so it seems to depend on components tolerances.
Our MSP is powered with 3.3V and runs on 16MHz:
UCSCTL0 = 0x0000
UCSCTL1 = DCORSEL_5;
UCSCTL2 = FLLD__1 +511;
UCSCTL4 |= SELA2;
Our (simplified) code:
static void ParseRXData() {
// Parse/Verify/Flash the received chunk of data
if (NewChunk) {
UpdateLCD((U8)((NumBytes * (U32)100) / NumBytesTotal));
__delay_cycles(51); // <- Workaround!
}
}
void UpdateLCD(u8 Value) {
// Depending on Value, calculate what digits to show
_LcdWrite();
// Adding the delay here wont work!
}
void _Lcdwrite(void) {
// Write LCDMEM
}
What he have found so far:
- When stepping through the code with a debugger, the error wont occur. But due to the USART Interrups the code execution is completely different anyway
- When running with connected debugger, it will stop in "_DebugBreak" without callstack so we do not really know where the crash happens exactly. The status registers don't show any fault or NMI
- When commenting out "UpdateLCD" the crash won't happen. But testing the function UpdateLCD in dedicated tests works perfectly and it is also used in other parts of the SW where it works.
- The __delay_cycles after UpdateLCD seems to fix the crash. Must be 51 cycles or more, 50 cycles will crash. Putting the delay_cycles in UpdateLCD won't work
- Reducing the CPU clock to 8MHz seems to fixes the crash
So any hint how to fix this? Up to now the workaround with the delay_cycles seems to work but we do not know why. And we don't know if it really fixes it on all devices.
Thanks!
