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.

MSP-EXP432P4111: BSL has timing issue, detect for 115200 can mistakenly detect 9600 baud instead

Part Number: MSP-EXP432P4111


 We have a weird intermittent BSL boot load problem where the BSL seemed to sync but always responded with 0x0, success, which should not occur when sending a bad password to erase and unlock memory.

I built the BSL in "debug" mode to figure out what was going on, and was able to replicate the problem on a launchpad. 

The file and function of interest is:



The else if clause failed at 115200 detect that it should have, but succeeded at 9600 baud clause. I'm thinking a timing aliasing/borderline case.

The BSL code goes south from that point.

This routine needs to be redesigned and re-written more robustly. Please, please, please.

One thing to consider is not to use 0x00 for a sync value response as 0x00 might be seen as 0x00 at any baud rate.

Another is to rewrite the bootloader to give better and more detailed error messages, I had to rewrite the bootloader to isolate the bug.

bob s.

  • Do you use the ROM based BSL with BSL scripter, right? And how do you trigger the BSL? 

  • I started with the ROM based BSL with BSL scripter but moved to a loadable BSL and bespoke scripter when I got error messages from the default tools with no detail.

    For the ROM based, my 432 code, on command via serial port, vectors to the BSL address. What was weird was it worked for a few months, then stopped working, which prompted the move to loadable to be able to debug. The non-ROM based identified the timing where (a valid) 115200 in leads to a mistaken 9600 detect.

    The TI supplied scripter when it detects a fault, does not provide any diagnostics. And the ROM based scripter uses 0x0 for the sync, which on diagnosis returns the same value even when not sync'd. 0 is 0 is 0 is 0. A  byte with a pattern in its bits would have been better.


  • fyi, this will be going into a smallsat, the idea is to make it reprogrammable from the ground after launch.

  • I have started doing diagnostics for my host driver. For the "bad password response" to unlock the BSL, I breakpoint using CCS and see a 0x05 going out (bad password error code) from the 432 but detect a 0x0 at my host, with 9600 baud verified on both sides. I don't understand how a password command can be detected ok on the 432, while the tx out from the 432 is mangled or not read properly on the rx by the host.

  • Hi Robert

    Sorry for the late response. I have try the baud rate 115200 several time with no problem. I have captured the UART waves by Saleae p401r_uart_115200.sal

    Could you capture the wave on your side?

  • Easier said than done. I'm working from home and would need help from over-stretched colleagues at this point for getting back into the lab and wiring up a saleae. I'm focusing on running the BSL from source (with your help in another thread), and have switched to yet another a higher priority task and haven't yet enough time to get back to this one. Argh.

  • to keep this forum's book keeping neat, I will close out this issue, though unresolved.