MSP430F5438 BSL Problems using BSL_Scripter

Today I have further determined that, with our release version of software installed on the F5438 chip, I am able to invoke the BSL, supply the password, and read out 64k using the TX_DATA_BLOCK command.  It seems to me that this means there is nothing wrong with the serial interface.  It seems that since I can have the BSL send lots of data read from the chip, but can only write small amounts (80 bytes or so) before the BSL fails, there is something wrong with the factory BSL or the flash write capabilities.  What do you all think? 

Thanks for taking the time to look,

Mike Raines

script file used to read from chip:

MODE 5438 COM4
VERBOSE
RX_PASSWORD Password042310.txt
TX_BSL_VERSION
TX_BUFFER_SIZE
TX_DATA_BLOCK 5C00 10000 readback.txt

Mike,

I did some bench test on my end and I couldn't reproduce the failure here.

Are you using an experimental silicon where there is a XMS marking on the chip?

What is the VCC voltage during programming?

If you do a repeated segment erase and write the file again, does it throw the same error?

Basically try this

MODE 5438 COM4
VERBOSE
RX_PASSWORD Password042310.txt
TX_BSL_VERSION

MASS_ERASE

RX_DATA_BLOCK BigFile.txt

SEGMENT_ERASE 0x5c00

RX_DATA_BLOCK BigFile.txt

Regards,

William

William,

     Thanks for the response.  Before I was able to try your suggestions, working with our hardware guys, we determined that our problem is some of the hardware in our implementation of slau265g chapter 5.  Following this entry is a description of the hardware problems from our hardware guy, JJ.  Please see if you can help him.

     The only thing I need now, software wise, are the following files necessary to compile the BSL_Scripter source code for usb use:

William,

     Here is the email from JJ concerning the BSL hardware interface problems:

That sounds strange.
I don't know what C5 is (a capacitor of course, but where and what for) and why it must have a negative bias. And why the TX line requires a negative bias. Or what the OpAmp has to do with it.

Fact is that while erasing (2mA), and even more when writing (3-5mA), the supply current for the MSP significantly raises. Why this causes a raise of VCC and other side-effects, depends on the hardware which I don't know. (and I doubt you'll give away the drawings, but if you do, I can take a look at it).

The Flash controller operating voltage range is 1.8..3.6V If voltage. But while programming,VCC MUST remain stable at its current level. From the users guide:
"If DVCC changed significantly during programming, this bit [VPE] is set to indicate an invalid result." It is not listed what a 'significant change' is, but I'd guess raising from 3V to 4V definitely is.

Jens_Michael,

     Thanks for taking a look.  The circuit is in TI slau265 rev g, chapter 5, figure 5-1, labeled Bootstrap Loader Interface Schematic.

Thanks,

Mike Raines

The guide has reached revision H, mine was F (only 6 weeks old!).

Hmmm, a really complex circuit. It has the advantage of powering the MSP from PC port, but usually, the MSP already has a power supply of some sort, and if the MSPs supply is for less than 3V, it will interfere or even short-circuit the 3V from the interface.

For this reason, I usually supply my RS232 interfaces from the MSP side. For normal RS232, I simply use a MAX202 chip and 4 capacitors. That's all. No OpAmps, no inverters. For a BSL interface, a MAX238 would be required (because of the 3rd incoming line). Or, (if there's no 5V supply available) one of the 3V derivates of this series. The only thing that's left are the two inverters required for TCK and RST. A simple transistor will do, if the PC software cannot be changed to simply invert their output signals.

But aside from the (imho) unnecessary complexity, I don't see why VCC should rise at all. Except if there's something wrong with your incarnation of the interface.

The low-drop regiulator is more or less a self-adjusting resistor. It will just limit the current flowing from in to out so that the output voltage will stay at the desired level. If the output voltage raises for some reason, it cannot lower it by drawing current to GND. It will just reduce the current flow from in to out to zero. Which does not actually lower the output voltage, just does not add more.

So why does VCC rise? This happens if a higher current flows into VCC than is drawn by the active components (MSP), or if current flows from GND to a more negative value. But why should it happen? The only possible way is through the input pins of the MSP. These have clamp diodes which allow any excess voltage above VCC or below GND on the input pins to be short.cut to VCC or GND. So if the input pin of the MSP is treated with a voltage above VCC, current will flow from the input pin to VCC. And when this current exceeds the current consumption of the other components powered by VCC (including the MSP itself), VCC starts to rise.

But where should this voltage come from? There are only three devices connected with the MSP.

1) IC1. It seems to be working correctly, as it keeps the 3V level under standby conditions.

2) D2. its purpose is bypassing any VCC_IN (external supply) >3V to the input of the voltage regulator and (more important) to the supply of the OpAmp. If it's defective, either the interface will (diode open) continue working with 3V instead of the higher VCC (e.g. 3.6V)  or (diode short-cut) bypass the voltage regulator and cause the OpAmp powering the 74AHC14 with the higher input voltage on IC1 IN instead of VCC.

3) IC2. If it is powered by a voltage >Vcc, it will also output a voltage >VCC to the MSP input pins, causing excess current flowing into VCC. This can be cause by either a short-cut of D2 (see above) or a bad soldering on pin 2 of IC3 (causing the OpAmp to latch-up and powering IC2 with its full supply voltage instead of VCC ro VCC_IN (whatever is higher). Also, using a 74HCT14 (or even worse a standard TTL 74(LS)14) instead of the 74AHC14 might cause excess current from the input pins into the outputs or the supply.

My suggestion is to check D2 and Pin2 of IC3.
Also, as a (ugly) workaround, solder a 3.3V zener diode between VCC and GND. It will (more or less) consume any excess current that keeps VCC above 3V. It's ugly because zener diodes are nor precise and begin drawing current below the given voltage (hence 3.3V instead of 3V), and because it will only fix the symptom and not the cause of the problem, but it will definitely keep VCC from rising to 4V :)

Good luck!

P.s.: the BSL interface is a nice universal solution for any kind of MSP target, but way too complex if you know the specifics of your target.

Mike,

I realize that there are missing USB files online. We're getting this fixed. In the meantime, see my attached project for BSL_Scripter that has all the necessary files that you would require to compile successfully.

But, as far as the circuit goes, Jens-Michael has some great recommendations there.

As for the VCC changing levels, are you referring to the TX and RX lines?

Also, I would monitor IC2 VCC too to make sure the VCC is stable around the voltage regulator.

Regards,

William

William,

     I couldn't access your attachment.  Is there something I don't understand about this site

or some other procedure?

Thanks,

Mike Raines

William,     I am now able to access your attachment.  Thank you.  we received the device.  Again, Thank you.

Our hardware guy, JJ is evaluating it to see why our implementation has issues.

Stay tuned,

Mike Raines

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..