MSP430F5438: BSL documentation contradictions

Hi

 The BSL in MSP430F5438 can't be edit.

For more details you can refer to this document

http://www.ti.com/lit/an/slaa419c/slaa419c.pdf

I read slaa419c to say that execution of BSL firmware from BSL (non-Main) flash were problematic, "forcing it to be locked from user edit."

By "it" does this mean that BSL flash is not eraseable, or not writeable?

But isn't the JTAG disablement "password" also within BSL flash? Does that mean the JTAG disablement "password" is not eraseable, or not writeable, too?

Hi Pete

Due to some issues in the device, we don't allow to program the BSL area. For more details you can refer to the SYS4 https://www.ti.com/lit/er/slaz289z/slaz289z.pdf

So why you want to erase that area? I recommend you to use the A version device instead.

Best regards

Gary

What means, "we don't allow to program the BSL area"?

If we need to permanently disable BSL access, despite the 256-bit BSL key (interrupt vector values), we would need to erase BSL flash, right?

If we need to set JTAG lock, we need to write ("program"?) the 16-byte JTAG key in BSL area to non-00s, non-FFs, right?

If we need to clear the JTAG lock later, knowing the BSL key, we need to clear the JTAG key in BSL area back to either FFs or 00s, right?

Or is someone with hands-on experience going to state whether or not reversible (recoverable) code protection on MSP430F5438 is impossible?

"I recommend you to use the A version device instead."

That kind of reply raises an emotional response in us.

Sure, as long as you're advising different hardware, I could just as well look at different families, different brands ...

By which I mean to say, that wasn't helpful.

Hi Pete

Please be easy.

I recommend you to use the version A , because you can see the difference between the version A and non- A version, the version A has a better performance. If you at the state to design the hardware or you can redesign the hardware you can replace it , that is a good choice. And you can see the TI.COM the msp430f5438 says "This product is not recommended for new designs." Right?

So your problem actually is how to lock JTAG?Due to I don't have a non-A version device, so I can't test it for you. You can test it in your side. I think you can lock the JTAG by change the JTAG signature. Because the JTAG signature is located in the protected BSL area, the operation must first clear the SYSBSLPE bit in the SYSBSLC register (write 0003h to the address 0182h). 

"Because the JTAG signature is located in the protected BSL area ..."

The TI documentation “… the BSL is not programmable … “ is a tad ambiguous, especially since BSL flash area erasure and rewrite is *essential* for JTAG code protection.

The words *could* mean, “the necessary logic for write access to BSL flash has been removed from the silicon, it is physically impossible to alter”

Or it *could* mean, “any attempt to program a substitute or alternative or customized BSL will fail, because of things too complicated to explain, so we say it is simply not customer programmable”.

Hi Pete

You are right, the description is not very clear for every using case, I think the mainly purpose is to tell customer not try to change the BSL image. Our purpose is to  solve the problem that you faced as soon as possible. The most effective way is to do the hardware test. So could you tell me what's the practical problem you faced? Let's deal with it first.

Right!

The primary assignment at hand is to implement non-permanent code protection on MSP430F5438 in a product that is very far down the development road, i.e., planning to ship in volume in a matter of weeks or very few months. Changing chip is absolutely out of the question; adding pads to unused pins will $$$ be $$$ very $$$ painful $$$. Permanent code protection is not an option -- our code is too green, the volume is too many, to afford scrapping products if anything requires reflashing the code.

Secondary objective is to convince IAR that BSL is not in ROM, so that at an absolute minimum their flash erase and programming does not (inadvertently, by misunderstanding) disturb BSL flash, but at best their debugging tools can examine and possibly even erase or reprogram it (especially the JTAG key) under developer control.

So my job is to collect the facts from documentation to prepare a plan -- a cookbook -- for disabling programmable flash access -- i.e., hacker snooping or copying -- in a way that can be reversed or overcome by the manufacturer. That issue is really being resolved in another question in this forum, "MSP430F5438: BSL programming how-to".

Meanwhile, this question here is an attempt to get contradictory, or at least conflicting or confusing, TI documentation straightened out, so that IAR for example cannot interpret it as "BSL is in ROM" and thus decline my support requests.

Hi Pete,

we understand you situation that you're short before production in high volume. However we also have to state that the "not recommended for new developments" for the F5438 non A is on the web for a very long time.

Besides the ERRATA sheet which mentions SYS4 and its related limitations to BSL we also have note in the datasheet under the memory sections table that BSL area is per-grogrammed with a TI BSL and cannot be changed. Because JTAG fuse mechanism resides in the BSL area too this will affect this mechanism as well. So it's a bit surprising to see that such a significant feature which is clearly stated to now work reliable on the non-A version should be implemented that late in your development cycle.

Again TI can not guarantee a reliable programming or erase of the whole BSL area therefore we do not recommend to use this feature.

So the A version is fully pin compatible what prevents you from using it? To clarify this and other business options we also can go offline via mail. Will contact you.

Dietmar -

the statement "Because JTAG fuse mechanism resides in the BSL area too this will affect this mechanism as well." -- is still a tad ambiguous, thank you. We don't need to know that it will be "affected" - we just need to know will it work at all, yes or no.

Can it be stated simply, "the JTAG fuse mechanism (key at 0x17FC-17FF) is ineffective/useless in MSP430F5438 because BSL flash programming is prevented -- in the silicon -- in this chip." ?

I am asking for clarification because the language "cannot be changed" is ambiguous in leaving the possibility "but can be used as-is if not changed" uncertain.  After all, we don't want to *change* the TI-BSL, we just need to use it, after a product may be returned from the field, to clear the JTAG fuse key, to restore JTAG flash reprogrammability.

If the MSP430F5438 does not support code protection by any possible scheme at all, please just say so.

Let's discuss this off-line.Thanks