MSP430F2617: Trouble Entering BSL - UniFlash and CCS

Hi Sam,

To invoke BSL on this device, you must pull the MSP's TEST pin high while holding RST low. This would put the device into BSL mode, then you should be able to send BSL commands to the device. So once the device is placed in BSL mode, you should only need the UART connection in order to communicate with the device via BSL.

You also need to ensure that you've selected MSP430F2617(BOOTLOADER) in Uniflash to make sure the PC side is working properly.

Reading through our Uniflash documentation, I am also not seeing that your FT232RNL is a supported device. If you simply set the FTDI chip to manually send the BSL commands to the device, it should work fine, but Uniflash is expecting a connection to some known debugger. The list of supported devices I am seeing are all TI XDS debuggers.

Hi Dylan,

By TEST pin, are you referring to something else? I am under the impression that it is "TCK" I am targeting since I am using an MCU with dedicated JTAG.

Going back to a previous question I had asked: https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1416057/msp430f2617-programming-flash-via-usb-bsl-vs-sbw-vs-jtag/5427459?tisearch=e2e-sitesearch&keymatch=%2525252525252520user%252525252525253A622603#5427459

It seems as though FT232, being a standard USB-UART bridge should work. I have seen other videos on YouTube with people using one. I do not see why this would be any different.

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/847026/bsldemo-now-supports-generic-usb-to-uart-adapters-and-the-rocket

I can tell that the device is doing something. I also tried using BSLDEMO itself with this command: ".\BSLDEMO.exe -tUSB -cCOM8 -d"
Here is the output:
MSP430 Bootstrap Loader Communication Program (Version 2.03 - 2019)
Mass Erase...
Additional mass erase cycles...
Transmit standard password...
BSL version: 2.13 - Family member: F26F - Process: 0760
Erase Check by file "(null)"...

It seems as though something is working correctly, otherwise I'm not sure how it found a BSL version, etc.

If it can't work with UniFlash, can I have some assistance to determine how to use it with BSLDEMO? I was told that I could use UniFlash from the previous post.

Thanks,

Sam

I have some additional information and updates to add to this:

I seem to have been successfully able to flash via BSL using BSLDEMO (BSL-Scripter) since my updated code seems to be reflected when I flash.

However, I still receive the following which tells me I'm doing something wrong:

MSP430 Bootstrap Loader Communication Program (Version 2.03 - 2019)
Mass Erase...
Additional mass erase cycles...
Transmit standard password...
BSL version: 2.13 - Family member: F26F - Process: 0760
Load/Verify new BSL "C:\VD\Firmware\VD_1.0_Firmware\Debug\VD_1.0_Firmware.txt" into RAM at 0x3100...
Program starting at 3100, 142 bytes... Error: 0
Program starting at ffbe, 108 bytes... Error: 0
Start new BSL (LARGE model > 1K Bytes) at 0xB2F2...
Transmit standard password...
ERROR: Synchronization failed!
Device with boot loader connected?

Everything seems to work, but those two error messages make me skeptical that something is still wrong here.

I am also not sure about the address ranges or what "LARGE model" at 0xB2F2 indicates.

Please let me know if you have any ideas, thanks.

Hi Sam,

Thanks for the added details. Looking back I do see the option for the USB to serial converter. Eason's original advice in the other thread is correct. When using with MSPM0 this is not an option. My mistake.

I meant the TEST pin on the MCU, but as you and Eason mention in the linked thread, on MCUs with dedicated JTAG pins this is TCK. So I do mean to say TCK. It also appears that Uniflash plus the serial converter should be able to take care of this for you. So my concern was originally that this sequence was not being followed correctly, but should be ok. You could double check by probing RST and TCK to ensure the signal appears as expected.

As for your updated info, the error you are getting appears pretty generic and does not help a lot with pinpointing the issue. I've found some threads with suggestions, including this one that indicates sometimes the polarity of the FTDI chips can lead to issues, which you may want to check. They also indicate that a simple wiring issue may cause the problem, but your comments on the connections earlier all appear right, and again you can double verify by probing the device pins and viewing the waveform. The "LARGE MODEL" indicates that it is compiled using the large memory model, meaning 20 bit addresses are used instead of 16 bits, This is necessary for devices like the one you are using, where the address space goes beyond 0xFFFF.

Hi Dylan,

It seems I cannot get UniFlash to work for whatever reason. I think it's a problem with configuration. Any chance we can debug that or should I just stick with BSLDEMO?

If I do stay with BSLDEMO, which appears to working, do you suggest that I try inverting the polarity using "-i" and "-j" arguments with BSLDEMO? I'm just not sure about why this would cause the error, as the error seems to be generated when the BSL does not respond with 0x90. I'm not too sure I understand what the purpose of this "synchronization" is because the documentation does not really talk about what it does.

Also - I do not have a method to probe RST and TCK because I do not have any exposed pins to probe in which those are attached. 

The sequence is for entering the BSL, and it seems as though I would not be able to update it without proper entry. That logically alludes to the sequence being correct. 

Thank you for clarifying about the memory model, I was reading about that yesterday evening and also came to the conclusion that it just refers to the various memory sizes that BSL 2.13 lives on.

The real question is: How is it that I can still program the MSP430 even though I am failing "synchronization"? And do I even need to care about said "synchronization"?

I would recommend trying the -i and -j arguments to try to get rid of the error, as you mention the error and its documentation leave a lot of investigating to be done. 

Particularly if we are unable to probe the signals it is going to be very difficult to diagnose what is wrong beyond trial-and-error.

Agreed on the point that it seems you are entering BSL mode correctly, as you are successfully flashing to the device. It seems the issue may just be in the way BSLDEMO is detecting it.

For your final question, I think the response is the above: it appears that the application is not correctly detecting that the device is in BSL mode, but for some reason still goes on to transmit the BSL data to flash the device. As for whether you need to care - I think that is up to you. If you are observing that it is programming the device properly, and you are getting the expected behavior, the only issue is that you get this error message but everything else looks great - then it seems like it can be ignored. I think to determine that you'd have to test a few devices and ensure that this is the case. 

Hi Dylan,

It seems that -i and -j are not available as parameters for the original BSLDEMO.exe. I tried it with BSLDEMO-2.01c and also was greeted with "ERROR: Illegal command line parameter".

Here is my command: .\BSLDEMO-2.01c.exe -tUSB -cCOM8 -d -i -j -b"C:\VD\Firmware\VD_1.0.txt"

Not sure what I'm doing wrong here but that does not seem to work at all.

Despite all of this - I am very disappointed that I cannot understand why UniFlash does not work for this.

The best thing I can think of doing is to compile the source by myself and toss in additional print statements so I can figure out what's happening, but I don't really have the time for my project to afford investigating further. Any insight would be appreciated.

I see...

Are you using Windows 11? One concern here is that these tools were developed a while ago and we have seen occasional compatibility issues with our older tools. In the past sometimes we have had to recommend customers revert to windows 10 to use these older tools.

I am also wondering why you had to stop using the MSP-FET, I see above you mention that it was working and then you moved to this FTDI part? 

Hi Dylan,

I am using Windows 11, yes. That could be something to consider.

I stopped using the MSP-FET because it was only meant to be temporary while I figure out BSL programming. My project is designed to be programmable via USB as it is a much simpler and less error prone method for my colleagues to be able to flash multiple boards. Can't plug in a USB cable incorrectly.

I've also historically had many issues with MSP-FET firmware becoming corrupted on Windows 11 machines and I want to avoid any additional pain points.

At this point my recommendation to continue debugging would be to try using a windows 10 PC since we are unable to probe the signals and debug this in a more manual way.