EmbeddedRelated.com
Forums
Memfault Beyond the Launch

MSP430F5438A BSL question

Started by Dave May 10, 2012
I'm looking for a little guidance about any "gotchas" related to the TI-provided flash BSL in the F54xxA series devices. So far, I've reviewed the SLAU319B documentation and come away with more questions than answers.

Please note, I have prety good long-term experience with using the ROM-based BSL on the older MSP430F149 series. I developed a set of in-house software tools for serially loading such devices in our factory environment. We've used these tools on several products which have F149 series devices. Now, we're planning on using an F543xA device. Looks like I need to rewrite my tools to support flash-based BSL, since TI modified the protocol.

One of my first concerns is a note in SLAU319B that pertains to BSL version 00.05.04.03, on the 543xA devices, that states "To invoke this BSL using the TEST/RESET method, the second low pulse on TEST must be shorter than 15 ."

Since I've always used DTR and RTS from a serial port under Windows to control *RST and TCK/TEST, I'm concerned that I'll never be able to hold that timing. Has anyone else faced this issue? How do the other BSL tools deal with this? Is this note still applicable to currently shipping parts or has it been addressed?

Second question: does the TI flash-based BSL protect itself during a mass erase operation? Seems pretty fundamental, but I haven't yet seen a discussion of how this works. My environment will likely consist of a production line with boards containing factory-fresh MSPs, which need one or two erase/program cycles before they go out the door. They are unlikely to be reloaded in the field.

Thanks for any pointers - I appreciate the group's time.

Dave Boyd

Beginning Microcontrollers with the MSP430

Have you considered using the Elprotronic REP430 Replicator? We have products that use both 1611 and 5438A chips and the Replicator works well for programing the chips. It has both JTAG and BSL connections. The REF430 uses a 5437 CPU which allows close to 200KB of target board code. The target system code is a data array that is compiled along wth the REP430 code. The REP430 board can either be powered with a DC adapter (8 - 10VDC) or powered by the target board thru the JTAG / BSL ribbon cable (we use the latter).

I did tweek the TI supplied JTAG software a little so that when the unit is plugged in, it waits until the 'GO' button is pressed before starting the programming process. I enhanced the error indicator so it does a repeat blink of the error code if there is a failure (ie if the error code is 3, the RED LED blinks 3 times, waits 1 second and repeats). I did find a minor error in one of the JTAG functions that does a quick memory read to get the XV2 device ID (two lines of code were reversed - the ref document was correct). If you aren't programming your boards, you can change the REF430 program to just erase / erase check / erase / erase check and then light up the Green OK LED.

SLAU319 does state "To avoid accidental overwriting of the BSL code, this code is stored in a secure memory location, either ROM or specially protected flash. To prevent unwanted source readout, any BSL command that directly or indirectly allows data reading is password protected."
----- Original Message -----
From: Dave
To: m...
Sent: Thursday, May 10, 2012 14:26
Subject: [msp430] MSP430F5438A BSL question

I'm looking for a little guidance about any "gotchas" related to the TI-provided flash BSL in the F54xxA series devices. So far, I've reviewed the SLAU319B documentation and come away with more questions than answers.

Please note, I have prety good long-term experience with using the ROM-based BSL on the older MSP430F149 series. I developed a set of in-house software tools for serially loading such devices in our factory environment. We've used these tools on several products which have F149 series devices. Now, we're planning on using an F543xA device. Looks like I need to rewrite my tools to support flash-based BSL, since TI modified the protocol.

One of my first concerns is a note in SLAU319B that pertains to BSL version 00.05.04.03, on the 543xA devices, that states "To invoke this BSL using the TEST/RESET method, the second low pulse on TEST must be shorter than 15 ."

Since I've always used DTR and RTS from a serial port under Windows to control *RST and TCK/TEST, I'm concerned that I'll never be able to hold that timing. Has anyone else faced this issue? How do the other BSL tools deal with this? Is this note still applicable to currently shipping parts or has it been addressed?

Second question: does the TI flash-based BSL protect itself during a mass erase operation? Seems pretty fundamental, but I haven't yet seen a discussion of how this works. My environment will likely consist of a production line with boards containing factory-fresh MSPs, which need one or two erase/program cycles before they go out the door. They are unlikely to be reloaded in the field.

Thanks for any pointers - I appreciate the group's time.

Dave Boyd





Steve,

Thanks for the info, but this isn't an application for a replicator - the product is buttoned up and only exposes a serial path, which by design can be both a USCI interface driven by application code, or the BSL Tx/RX path.

I had seen the note about "specially protected flash", but since I've also read about techniques for replacing the flash-based TI BSL with a user BSL, had concerns about how easy it was to lose it.

What most concerns me is whether there is critical timing around entry into BSL via the usual TEST/TCK toggle with *RST on these devices.

Dave

Yes, the errata sheets for the 54xx do say <= 15ns between TEST pulses to enter the BSL. Have you considered going to the 55xx series? They do not have that restriction. The Replicator does have a BSL output using UART0 of the 5437. The SLAU319 code looks like it is for an older 149 based unit though.

SLAU319 also has PC code to interact with the 543x and 5xx (includes the 54xxA devices) families using a COM port. There isn't anything in the code to indicate it won't work with the chips that have the SYS10 bug - but considering what SLAZ057n says, I don't see how it will work - perhaps they use an external circuit that is triggered by the COM DTR / RTS lines???

In order to erase the BSL (or INFO) areas, you need to change the LOCKINFO bit and only segment erase will work. MASS_ERASE does not affect the BSL or INFO areas.
----- Original Message -----
From: Dave
To: m...
Sent: Friday, May 11, 2012 06:25
Subject: [msp430] Re: MSP430F5438A BSL question

Steve,

Thanks for the info, but this isn't an application for a replicator - the product is buttoned up and only exposes a serial path, which by design can be both a USCI interface driven by application code, or the BSL Tx/RX path.

I had seen the note about "specially protected flash", but since I've also read about techniques for replacing the flash-based TI BSL with a user BSL, had concerns about how easy it was to lose it.

What most concerns me is whether there is critical timing around entry into BSL via the usual TEST/TCK toggle with *RST on these devices.

Dave



That should say 15 micro seconds instead of 15 ns.
You have a chance to do 15 us and almost no chance to do 15 ns.

Blakely

--- In m..., "Steve Mayfield"
wrote:
>
> Yes, the errata sheets for the 54xx do say <= 15ns between TEST
pulses to enter the BSL. Have you considered going to the 55xx series?
They do not have that restriction. The Replicator does have a BSL
output using UART0 of the 5437. The SLAU319 code looks like it is for an
older 149 based unit though.
>
> SLAU319 also has PC code to interact with the 543x and 5xx (includes
the 54xxA devices) families using a COM port. There isn't anything in
the code to indicate it won't work with the chips that have the SYS10
bug - but considering what SLAZ057n says, I don't see how it will work -
perhaps they use an external circuit that is triggered by the COM DTR /
RTS lines???
>
> In order to erase the BSL (or INFO) areas, you need to change the
LOCKINFO bit and only segment erase will work. MASS_ERASE does not
affect the BSL or INFO areas.
> ----- Original Message -----
> From: Dave
> To: m...
> Sent: Friday, May 11, 2012 06:25
> Subject: [msp430] Re: MSP430F5438A BSL question
>
> Steve,
>
> Thanks for the info, but this isn't an application for a replicator
- the product is buttoned up and only exposes a serial path, which by
design can be both a USCI interface driven by application code, or the
BSL Tx/RX path.
>
> I had seen the note about "specially protected flash", but since
I've also read about techniques for replacing the flash-based TI BSL
with a user BSL, had concerns about how easy it was to lose it.
>
> What most concerns me is whether there is critical timing around
entry into BSL via the usual TEST/TCK toggle with *RST on these devices.
>
> Dave
>
>
>



You're correct...I need new glasses ;)

----- Original Message -----
From: Blakely
To: m...
Sent: Friday, May 11, 2012 13:51
Subject: [msp430] Re: MSP430F5438A BSL question

That should say 15 micro seconds instead of 15 ns.
You have a chance to do 15 us and almost no chance to do 15 ns.

Blakely

--- In m..., "Steve Mayfield"
wrote:
>
> Yes, the errata sheets for the 54xx do say <= 15ns between TEST
pulses to enter the BSL. Have you considered going to the 55xx series?
They do not have that restriction. The Replicator does have a BSL
output using UART0 of the 5437. The SLAU319 code looks like it is for an
older 149 based unit though.
>
> SLAU319 also has PC code to interact with the 543x and 5xx (includes
the 54xxA devices) families using a COM port. There isn't anything in
the code to indicate it won't work with the chips that have the SYS10
bug - but considering what SLAZ057n says, I don't see how it will work -
perhaps they use an external circuit that is triggered by the COM DTR /
RTS lines???
>
> In order to erase the BSL (or INFO) areas, you need to change the
LOCKINFO bit and only segment erase will work. MASS_ERASE does not
affect the BSL or INFO areas.
>
>
> ----- Original Message -----
> From: Dave
> To: m...
> Sent: Friday, May 11, 2012 06:25
> Subject: [msp430] Re: MSP430F5438A BSL question
>
>
>
> Steve,
>
> Thanks for the info, but this isn't an application for a replicator
- the product is buttoned up and only exposes a serial path, which by
design can be both a USCI interface driven by application code, or the
BSL Tx/RX path.
>
> I had seen the note about "specially protected flash", but since
I've also read about techniques for replacing the flash-based TI BSL
with a user BSL, had concerns about how easy it was to lose it.
>
> What most concerns me is whether there is critical timing around
entry into BSL via the usual TEST/TCK toggle with *RST on these devices.
>
> Dave
>
>
>
>
>
>
>






Memfault Beyond the Launch