MSP430F5659: BSL-Scripter corrupting reset vector with certain binary files

Hi,

It sounds like the fact that every other byte is a perfect match, and that the code flashes flawlessly over JTAG using CCS or MSPFlash, this would point directly to a known, subtle quirk in how the TI BSL-Scripter handles specific Intel Hex (.hex) or TI-TXT (.txt) file formatting structures. The bootloader (BSL) is not corrupted on purpose. Instead, BSL-Scripter is dropping exactly one data payload byte due to a packet alignment or parser mismatch at the very end of your binary, which shifts the final written byte (0x83) out of its expected boundary, leaving behind the default 0x00 in the higher byte of the reset vector. A couple of things that you can try:

1. Fix Missing Odd-Byte Padding in Your Compiler Output --> Open your CCS project properties, navigate to Build > MSP430 Hex Utility > General Options, and ensure that Fill flash holes or Even-byte alignment padding options are enabled. Alternatively, ensure your linker command file aligns all final flash sections to a 2-byte boundary using the align(2) directive
2. Verify Line-Ending Formatting in the Script File --> The USB BSL interface on the MSP430F5659 acts as a strict packet-based parser. If the failing firmware generates a .hex or .txt file where the very last line containing the reset vector (@FFFE or the hex EOF record) lacks a trailing Carriage Return/Line Feed (CRLF), BSL-Scripter will fail to transmit the final block chunk correctly.
3. Switch Output Generation Formats --> If you are passing an Intel Hex (.hex) file to BSL-Scripter, the tool must internally convert those records into address-payload blocks. For many developers, the conversion loop inside BSL-Scripter can stumble depending on how your specific compiler packages the upper-memory addresses. Change your CCS Hex Utility configuration to generate a raw TI-TXT (.txt) file instead of Intel Hex. The TI-TXT format maps cleaner into the raw memory chunks that the BSL expects, eliminating parser translation drops

-Brian

This would seem to ignore the information provided. It isn't an odd byte or lack of CRLF, and it sure looks like TI-TXT to me.

From the input files:

Good:

@ffd8
1E 83 1E 83 1E 83 1E 83 1E 83 1E 83 1E 83 00 80 
1E 83 1E 83 1E 83 1E 83 1E 83 1E 83 1E 83 1E 83 
1E 83 96 82 1E 83 02 83 4A 14 C9 0E C7 0D C6 0C 
4F 49 5F 0E 40 18 5A 4F D4 87 07 93 02 24 D6 03

Bad:

@ffd8
1E 83 1E 83 1E 83 1E 83 1E 83 1E 83 1E 83 00 80 
1E 83 1E 83 1E 83 1E 83 1E 83 1E 83 1E 83 1E 83 
1E 83 96 82 1E 83 02 83 4A 14 C9 0E C7 0D C6 0C 
4F 49 5F 0E 40 18 5A 4F 50 85 07 93 02 24 D6 03 

Thanks Brian for your reply!
Sorry my post is misleading, I mentioned the format to be "TI-HEX", but that does not exist. It is in fact a TI-TXT format that is being used for all files, as per your suggestion.

Hi,

I have reached out to our software team for additional support. This issue doesn't appear to be trivial and may take some time to find the root cause and a solution. Can you provide us with the setup you are using with the BSL-scripter (programmer and operating system)?

Best Regards,
Brian

The BSL-Scripter program should produce a log file. Examining the log, especially around the parts where it is writing to/near the reset vector might be helpful.

The source code is available but the authors are of the new school which thinks comments are over-rated so figuring out what it is doing hat way is a chore.