MSP430F5438 Firmware upgrade

aBUGSworstnightmare said:

Well, it is possible to re-program the firmware from the eZ430-RF2500 to the one from CHRONOS, BUT you need a MSP-FET430UIF JTAG t do the job (see here for details http://processors.wiki.ti.com/index.php/EZ430_Emulator_Upgrade). Maybe you know somebody who has one and is able to do it for you. If not, I highly recommend buying a MSP-FET430UIF (http://processors.wiki.ti.com/index.php/EZ430_Emulator_Upgrade).

Hello!

What about LPT JTAG? Since buying MSP-FET430UIF would take a long time, I could use this one etched on my own PCB. Is it sufficient for EZ430 upgrade or maybe even MSP430F5438 operations?

Hi Socrates,

LPT JTAG only works with Windows XP or 2000. So, if you have this at hands and your PC still has the parallel Port it's o.k.

You can use it for updating the eZ430U (JTAG mode is used) and/or for debugging all MSP430 devices in JTAG-mode! This tool does not support Spy-Bi-Wire!!!

But, since you have the eZ430U at hands,  you can use the eZ430U when you need to debug in Spy-Bi Wire mode (i.e. if you need the JTAG pins for your application on devices with low oin-counts).

So, go ahead and get one! It's cheap and seems to available off the shelf!

Rgds
aBUGSworstnightmare

So I have updated my EZ430-RF2500 USB side board with the newer firmware successfully, however it did not recognize my F5438 in IAR, when I connected SBWDATA and SBWCK wires to the board (GND is through the USB wire). Starting download and debug @ IAR pops up a preparing window, it hangs for a while and then error comes out asking to check the hardware. Maybe I need more than 3 wires for SPI-BI-WIRE in F5438?

 

EDIT: got it working. Problem was bad USB ground, had to connect it by wire in JTAG connector.

Socrates said:

I connected SBWDATA and SBWCK wires to the board (GND is through the USB wire).

What about the MSP supply voltage? Is there one at all? Same level for target and programmer?

Well, I've powered experimental board from USB and also powered EZ430 from USB, both of them have 3.3V or 3.6V (can't remember exactly) voltage regulators, so I suppose both have same levels. However, I got it working, seems like I am able to download and debug directly from IAR. Too bad initialize, erase and firmware upload takes a really long time (20-30 sec) :(

I don't know TI politics, but when I buy a devboard, I believe there should be a programmer. Here was none... Another headache even before the development start, whats next then?..

Socrates said:

I don't know TI politics, but when I buy a devboard, I believe there should be a programmer.

I believe there is a bundled offer for both, but there are many customers who already have a programmer for the last MSP devboard and don't need one. Forcing them to buy one programmer for each devboard they buy wouldn't be a good idea.

Also, there are a wide variety of programmers, not only from TI. We even have an RF programmer, so we can just plug it on the the device (usually an electrical installation somwhere in the edge of a factory building), then go the the laptop in the next room with power supply/network and start flashing. No risky cable, no problems with electrical potential (or devices are attached to live wire usually). Just pick a programmer of your choice.

If you buy a car, it too doesn't come with a drivers license, even if you need one to drive it (legally).

Socrates said:

Too bad initialize, erase and firmware upload takes a really long time (20-30 sec) :(

You never worked with a PIC? There programming wasn't in-circuit, and flashing even the smalles 2kB devices took an eternity. On the MSP it is blazingly fast.
Sure, the update of 128k firmware on the ATMega128 through ethernet is still somwehat faster :) But MSP is okay. Plain flash writing speed is ~25k/s and JTAG isn't the fastest connection for pushing data.

Jens-Michael Gross said:

If you buy a car, it too doesn't come with a drivers license, even if you need one to drive it (legally).

No, its like buying a car without wheels, maybe You have them from Your previous car? :) You can't drive it! What if the car is the first You've ever bought? :P

 

Jens-Michael Gross said:

You never worked with a PIC? There programming wasn't in-circuit, and flashing even the smalles 2kB devices took an eternity. On the MSP it is blazingly fast.
Sure, the update of 128k firmware on the ATMega128 through ethernet is still somwehat faster :) But MSP is okay. Plain flash writing speed is ~25k/s and JTAG isn't the fastest connection for pushing data.

Heh, true, I didn't. I am working mostly with Atmel and now migrating to TI. All I had AVRs, ARM9 (SAM9260 and 9263) and also Stellaris ethernet board were faster :)

Btw, that RF JTAG is amazing idea. Could be cheaper tho.. :)

 

Right, so I have to get this old topic up, since my problem is getting worse. I need to upgrade MSP430F5438(A) using RS485. There is a bootloader, which allows firmware update after a sequence on TEST and RST pins are done. It is impossible to control these pins using RS485 and it is impossible to do this when the msp430 is running (I mean to set the sequence for itself), because there has to be a pulse on TEST pin when RST is low (which means the processor is in reset state). What suggestions can I receive?

Here are my options, however difficult or impossible ones:

1. The idea is to write my own bootloader, which would rewrite internal flash of program area (isn't it prohibited?) and then jump to that area after rewriting. This solution is very complicated and also requires assembler skills, I believe.

2. Use second processor, however since the board has to be VERY small and the power consumption MUST be low, I have to lower the power consumption as much as 5mA, when running processor, rs485 and 3 additional chips.

Maybe there are already done options?

Thank You.

The bootloader of the 5438 works basically this way:

The hardware detects the proper entry sequence and sets a 'secret' register bit. Then it starts the bootloader as normal software. After a reset, the bootloader area is accessible. There, a function detects whether the secret bit is set or not and then either locks up the BSL area for normal access and jumps to the reset vector or starts the bootloader.

It is possible, bu tnot trivial, to start the bootloader from inside the application manually, without need of this pin toggling sequency. There are some appnotes about this (BSL programming/usage etc.).

RS485 won't work with the original bootloader, as it is unidirectional and thebootloader does not handle the direction control. There are, however, some hardware tweaks which do direction control automatically using a monoflop that triggers on the start bit and expires after a byte time. It requires, however, at least one monoflop expiration period before you can use the opposite direction. If you're programming the protocol yourself, it is no problem to insert a delay, but I'm not sure whtehr it will work with the bootloader.

You can write your own bootloader. On the 54xxA devices, you can replace the original one. It requires some assembly skills (no C++ init has happend at this place) and you'll nee dto follow the design guidelines for teh entry point and such.
Or you can include a bootloader into your applciation code. It is executed as the first function, checks whether necessary and then downlaods the stuff. Main problem here is that if the bootloader resides in main flash, it can be erased by a mass ersae and/or has to overwrite itself during the setup. So it must be configured to run from a place where it isn't subject to its own deletetion (e.g. ram). Furthermore, if the update fails, it shoudl leave the device in a state where at least the bootloader is still working.

There are several threads about this. Personally, I use a bootlaoder that reeives the data during normal operation (wireless) and stores it in a storage/mirror area of the flash. After a reset, the mirror area is checked (with CRC) for a valid mirror, and if there is one, it is copied to execution flash area and then deleted. The area of the copy function is never updated by itself (and it is identical across firmware revisions). So if an update fails because of e.g. power loss, there is still a valid image and a working copy funciton (yet maybe no code to receive further firmware revisions, so only checked and working images may be updated this way) and the copy process can restart until the image has been successfully copied and then erased.

During development (with non-working update channels) or on an empty device, the firmware must be flashed with JTAG or the original BSL.