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.
MSP430F5515, BSL 06.05.34
I have written a PC-based USB bootloader application that writes a TI.TXT file to my MSP430F5515 custom board. All works correctly except for the last 128 bytes of flash (0x14380 - 0x143ff). When I send the BSL command I get a BSL Core response message of 0x00 (Operation Successful) for each USB packet sent, including the last 128 bytes. However, these last 128 bytes are 0xFF instead of the correct value.
Any idea what I could be doing wrong?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Luis RC:
Luis RCHave you tried checking the packets (and perhaps comparing them with USB Firmware Upgrade Example) using a USB bus analyzer?
Yes. I can see the correct data beings sent and a positive response from the BSL.
Actually, have you tried breaking the packet in smaller chunks?
All of my core commands are 62 bytes.
SLAU319 says that the F5515's BSL has a buffer size of 62 Bytes.
I do not see anything in SLAU319h about BSL Ver 06.06.34
In reply to MikeH:
The buffer probably is not getting flushed. RAM BSL requires the host to send a read command, a CRC, a write command or a reset command to a new location in order to trigger a buffer flush. This is because BSL buffers all data until a 128 byte block is received and then writes the data to device. If an image did not end on a block boundary the data is not transferred to the device. To flush the buffer send the device a dummy command after you have written data to device. Try something like BSL_LOAD_PC command.
In reply to Arthi Bhat1:
Arthi Bhat1RAM BSL requires the host to send a read command, a CRC, a write command or a reset command to a new location in order to trigger a buffer flush. This is because BSL buffers all data until a 128 byte block is received and then writes the data to device.
Hmmmm....That sounds like a pretty important thing to include in the documentation. Did I miss something?
I worked around this issue by changing my linker file to end the load area before the last 128 bytes, which seems to work OK.
Edit: This stopped working when my file size changed. See below for fix.
I tried BSL_LOAD_PC, which did not work. However, I then tried TX_BSL_Version which does seem to work.
I highly recommend including this information in the documentation (unless I missed it).
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.