MSP430F5437 BSL problem

I'm having similar BSL ambiguity issues with the MSP430F5438A.  I have tried using both the TCK and TEST pins methods to invoke the BSL sequence, but am unable to enter the BSL mode.  Using a JTAG programmer, I loaded a small program that toggles an LED at 1 Hz.  After all my attempts to enter BSL mode the small app code starts immediately (LED blinking).  In SLAU265D Section 6.1 states that the second low pulse on TEST must be shorter than 40us.  Using the TEST pin method pulses the pin high twice, not low.  Should this be inverted?

I've made some progress and have managed to enter BSL mode and program the MSP430F5437 under certain conditions.

First of all, for the 54xx, you use the TEST pin, not TCK (poorly documented!)

I took the source code from BSL_Scripter, provided by TI, and used that as my starting point.  From there, depending on your hardware interface, you can flip the RST and TEST signals in the code to get the right setup.  I'm not sure about entering BSL mode with manual push buttons.

However, there are still more issues.

Firstly, the bsl_scripter application has a severe bug.  If the resulting TXT file being downloaded has its last section as an odd number of bytes, the download will fail.  The last section must be padded by an 0xFF byte (or so I have been told -- not tested that yet).  If you use their example file big_file.txt, the bug conveniently does not appear and the download will succeed.

Secondly, exiting BSL mode is flakey at best.  The errata for the part states that you must toggle TEST several times before exiting BSL mode, otherwise you get a weird problem.  They state that BSL mode will not exit without the proper sequence, but that is not entirely true.  Instead, your app will execute, but you will not be able to enter BSL mode again until you cut power and restore it.  I'm still working on the proper way to exit the BSL mode.

Anyway, to summarize, use the TEST pin and the source for BSL_scripter as the starting point (run BSL scripter in 5438 mode in the script file).

Then, be aware that the bsl_scripter will fail if you have an odd number of bytes in the last section of the TXT file, and also that the bsl scripter utility will not correctly 'exit' the BSL mode for the 54xx, even if your application starts executing.

Eric

Hi Mr. Eric,

We are using MSP430F5418 as our target device and facing the similar problem you had mentioned on 10th Dec, 2009.

Well we have tried several methods, that why exactly the BSL mode is not getting set up, till now we have not received any solution from TI guys.

But We have observed waveforms on RXD pins -

which is Continous low for 833Usec and then some data is there, well till now we have not considered what the data is.

One Trial TI people had asked me to do is Diectly jumping to the BSL Flash area and debuggig what exactly is happening there. But the data is loaded with some fixed data 0x3FFF across the boat. Presently the project is halted and there is no progress. Besides that we have checked the Entry sequence waveform which is correct as per the doc (of course on TEST and RST pins). But after that we are absolutely clueless.

Do you have any progress so far??

Regards,

Shriram Gaur

I think the debugger generates more bugs of its own.

Eric,

This post is not very recent - so you may have figured out the answers already.

Eric Fattah said:

Secondly, exiting BSL mode is flakey at best.  The errata for the part states that you must toggle TEST several times before exiting BSL mode, otherwise you get a weird problem.  They state that BSL mode will not exit without the proper sequence, but that is not entirely true.  Instead, your app will execute, but you will not be able to enter BSL mode again until you cut power and restore it.  I'm still working on the proper way to exit the BSL mode.

Please check errata JTAG 20 in the MSP430F5438 errata document

This gives you the expected exit sequence for the 430 BSL.

Regards,

Priya

Shriram,

1. Which pins are you using for the TX/RX?  TA0.0 TA0.1 ?

2. Are you using the BSL scripter utility?

3. Keep in mind that the Flash BSL in the 54xx is different than the ROM BSL in other devices.

4. The first indication that you have entered BSL mode is that the RX pin will be driven high by the device.  From there on, if you follow the flash BSL protocol, you should have luck.  Note that the ROM BSL requires sending an 0x80 character, but that is not what you do for the flash BSL.

Eric Fattah

Liquivision Products

Another comment on this thread.  I finally got the 5437 BSL to work 100% of the time.  In addition to everything I mentioned previously, I need to call the InvokeBSL() function at least twice to guarantee entry into BSL mode.  In other words, I apply the BSL entry sequence several times in quick succession.  Otherwise, entry into BSL mode does not always occur.

Given the number of changes I had to make to get the whole thing to work, I'm amazed that anyone has managed to use these parts so far !

Eric

I have also been able to get the bootloader routines working on the XMSP430F5438A.  I have found out that since this version of MCU is marked with and "X" (I assume for experimental) that it did not get the flash bootloader installed on it.  I had to get the compiled bootloader file from the TI tech support to move forward.  After loading the bootloader program, I was able get into bootload mode by using the TEST pin.  Although, the bootload routines would not communicate at the documented 9600 baud.  Rather, the baud rate was about 6666, verified with an Oscope.  I assume that this was due to the internal oscilator not being trimmed since I have the "X" version.  After figuring those two things out, I was able download a full application file using the bootload routines.

While going through this process, I also tried to use the FET to verify the flash contents in the bootload section, and saw all 0x3FFF.  I don't believe this is correct since this area of flash is protected, so you can't read back valid contents in that area.

Dear Mr. Eric,

Please check the answer to your qouestions (red coloured) -

We have also been through all the hard issues - but now we have one major issue left open: The mass erase command does not erase the info segments. Any ideas how solve ?

We are using the F5418 non-A.

Sorry, Still struggling with the Mass erase command and making it work 100%, most of the time im unable to erase the flash. Im using 5418(non A), but i dont know why its not working. till now only 2 times it has been worked.

Can you tell me what additional precautions you have taken whle using the device and programming via BSL.

Im using SLAU265E BSL scripter utility.

PS - I have notice that both the times when BSL worked, TXD pin was also PULLED up for Duration of RXD pin is pulled up. Rest of the time when BSL fails to erase flash, the TXD is kept low.

Can you explain this particular situation ? Im still struggling with this.

Regards,

Shriram

We have build our own C# programming software, but based on the TI scripts. We are using RxD and TxD as you normally do in RS232.

It is important to start every new try by switching off power supply, otherwise the mass erase will fail in the second try.

Are you waiting for the acknowledge from the 5418 after the mass erase ?

I also modified the C-code from the BSL scripter.  I also found that at first, I HAD to cut power, and then re-apply power, otherwise the mass erase would fail.  However I have been able to cure that problem by calling InvokeBSL() twice, before trying any commands.  By calling InvokeBSL() twice, I can get the BSL to work 100% of the time without cycling power.  In the beginning, when I couldn't get it to work, at one point my code was actually correct, but it didn't work until I accidentally cut power and reapplied power.  So that is a major point.

Eric

Dear Sir,

when i try to download the Application code to the MSP430F5438 using BSL programmer(BSL_Scripter.exe)

i am facing following Problem...

BSL Scripting application 1.06
The local time is: 12:19 on 30.04.2012
------------------------------------------
Initializing, Mode: 5438 COM: COM1 DONE
Changing Baud Rate to 9600 DONE
Mass Erase: FAIL(ee)
RX Password: FAIL(ee)
Writing MSP430TB.txt to device: FAIL writing data block starting at 5c00
CRC from 5c00 of 4096 bytes to 982b FAIL....

please help me...

Thank you..

It seems that you are not getting any feedback from the processor ?

As always, there could be several reasons for no contact. I would use a check list like this:

- Is hardware correct (correct pins and levels) ?

- Try another RS232 driver - we have seen some USB based RS232 interfaces working well and others not at all

- Follow the initial sequence on an oscillosope

- set up another PC as a simple RS232 sniffer by just connecting the receive signals from that PC and see what happens from each end. We often use the simple sofware terminal.exe to see what happens.