Flash persistence through BOR/POR on MSP430F5529

Hi,

I intend to work with with F55xx but have not started yet. Hope you do not mind that I ask you a few questions.

(1) Between those 200 resets, did you ever connect a JTAG Tool to your system? Could it be that the JTAG Tool was doing those things behind your back.

(2) Is your custom bootloader protected from unintentional activation? What are the mechanisms, if any, are you using?

(3) Did you use the marginal read modes to verify Flash programming?

-- OCY

OCY, ask as many questions as you wish...

(1)  JTAG has not been connected to any of the units that have demonstrated this problem.  At this point we have approximately 50 beta units all bundled up in proper housings where the JTAG is no longer accessible.  Unfortunately, whenever we are trying to reproduce the problem, it won't cooperate.  It just seems to pop up every now and then when we aren't expecting it.  The point of our custom bootloader is to facilitate firmware updates i the field via USB (common interface across instrument types).  When I debug the main firmware via JTAG on a development board, the bootloader typically isn't loaded just to keep the configuration more manageable.

(2) I do takes steps in the boot loader to protect the flash write routines from aberrent execution due to program counter corruption, etc...  However, when I erase in the bootloader, I erase the lower bank first and then incrementally erase segments up to the bootloader reserved segments.  If any of the bootloader erase code was somehow getting executed, I would expect to see whole segments (at the very least) get erased.

(3) I have not tried testing with the marginal read modes.  Thank you for that thought.  I'll rewrite the verify routines to use them and see if I can detect any weak bits.

Thank you very much, your thoughts are appreciated.

It sounded to me that your custom bootloader uses the traditional method found in older F1xx, F2xx, and F4xx family members. It is my understanding that F5xx and F6xx have new features to support custom bootloader and you are not using them.

Is your custom bootloader stored between 0x1000 and 0x17FF? What is stored in location 0x1000 to 0x100F? How about 0x17F0 to 0x17FF?

You are correct that I am not using the BSL flash block.  I locate my custom bootloader at E000 to FF80.  This is basically because I still need to protect the Flash vector table for use by the bootloader from FF80 to FFFF.  As a result, it would be more of a hassle to use the BSL block than not.  Now, if the flash vector table was located in the BSL by default and the 430 had a register for modifying the vector table base address...

In the end, I'll probably end up using the BSL space for const storage if I run out of room in the INFO blocks.  To answer your specific question, it currently still holds the default BSL code which we aren't using.

I do not know why you need to protect the Flash vector table for use by the bootloader. I think you probably only need a few of them and you can copy them to RAM to uses for the duration of booting only with SYSRIVECT set.

I think the BSL Flash provides a lot of protection against mishapes. But 2KB may be too small for you. What kind of features do you have in your 8KB bootloader? Do you also have a custom program in PC to feed it? Which peripheral do you use for bootloading? Is it not USB?

BTW, other then your bootloader, does your "Application" program erase/write Flash (including Info Flash)?

I am planing to modify the TI USB-BSL and the corresponding PC program. I want to: (a) Add CRC check for the Main Flash before it allows normal RESET. (b) Add marginal read modes checking. (c) Scramble/encrypt the object file to be loaded and unscramble/decrypt inside the USB-BSL Any suggestions/comments?

Back to the original problem. Are you sure no other bits in the entire Main Flash are changed? In addition to, or instead of, checking the signature only, you may want to check the CRC of the entire Main Flash.

In general I believe it to be a wise choice to always protect the flash vector table.  Let me ask you this - what do you have if in the field, power is interrupted or there is a spurrious reset after the flash vectors are erased as part of update, but before they get reprogrammed?  You have a unit in the field with no hope of recovery.  By treating the flash vector table and bootloader as ROM'd features (not field updateable) and then always using RAM vectors in the main application, the system is always recoverable without coming back to the factory.

You are correct that another reason for not using the BSL section is that it is indeed too small to fit my entire bootloader.  I like the idea of having the bootloader in a separate block that can be individually locked - but given the small size and without having the ability to protect the flash vectors, it's not really buying me anything at this point.  In my opinion, partially protecting the bootloader is only marginally better than not protecting it at all.

Our bootloader has a common interface that I use across many of our USB-based instruments, from this one using a MSP430F5529 to a couple using the TMS320VC55x family DSPs, and another using an ARM.  The common interface allows me to use the same tools for field updates, regardless of product.  I once believed in the safety of keeping all flash erase and write routines out of the instrument and only loading them into RAM from the external interface during the update process.  That is, until I had to support multiple disparate devices with the same application.  Managing the external update code blocks and varying protocols was a mess.  Now we've settled on a common interface with a feature set that handles all erase/program/verify functions.  It also allows me to query the device to get instrument type, hardware platform, bootloader revision, etc...

The application firmware can only erase and program INFO_D.  It uses this area for user calibration values.

The TI USB-BSL is a fine place to start, just realize (if I'm not mistaken) that you won't have much room for additional code before you outgrow the 2kB BSL area.  Without modification, the USB-BSL is still rather versatile in that you can use it to load and execute in RAM whatever custom code you wish.  I'm not familiar with the corresponding PC program or drivers - I've always rolled my own.  (a) I think your idea of checking a main CRC before jumping into freshly programmed code is a wise choice.  (b) in the past I've never bothered with marginal read testing, but if it helps detect problems I'm all for it. (c) I usually don't secure the code while tranferring to the instrument.  Unless you've got some super IP, it's a lot less work to just code something from scratch than to try to take somebody's image and disassemble/reverse-engineer it.  The only way that it is cost effective to take someone's firmware image is if they are making an exact clone of your product.  Others may disagree with me on this point - to each their own.

As far as my problem is concerned, right now I do not know if anything else has changed.  I created a new firmware image where all unused space is set to A5h so that I can tell if anything changes outside of my program code.  That code was loaded into a number of the units late yesterday.  Now it's just a waiting game to see when the problem next pops up.  The main reason for the signature was simply to tell if the part was fully programmed.  I've never had a problem in the field with flash devices having altered contents, so I've never been overly paranoid about checking the integrity of the image on boot.  If I was doing medical, military or aerospace applications, that would be another matter.  In those fields, paranoia appropriately comes as part of the job description.  I have seen plenty of times where a user unplugs an instrument or the battery dies during update.  That is common and primarily what I'm trying to protect against with the signature.  You are correct that the CRC check is a more robust check.

"What do you have if in the field, power is interrupted or there is a spurrious reset after the flash vectors are erased as part of update, but before they get reprogrammed?"

It depends on how the BSL is implemented. Some of the custom BSL implemented on 1xx, 2xx, or 4xx that I have seen do not use interrupt themselves. The BSL code resides in Main Flash, and they depend on the RESET Vector (at 0xFFFE-0xFFFF) to start. They are capable of restarting and reprogramming the rest of the Flash, including the vectors as long as the BSL code itself and the RESET Vector is still preserved. If the BSL itself needs to use some of the interrupts, then the vectors as well as the ISRs of those interrupts also needs to be preserved. The custom BSL for 5xx or 6xx could have their own interrupt vectors and ISRs totally independent of the contents of the Main Flash -- whether it is erased or trashed.

I just remembered that there is/was a bug in a different MSP430 chip that can accidentally erase a 64-byte block of main flash inside a 512-byte sector without effecting the other 448 bytes. Could it be that you discovered a similar bug? Exactly how many bytes are erased and what is the address range?

I just remembered  that there is/was a bug in a different MSP430 that could erase a 64-byte block of Main Flash within a 512-byte Sector without changing the other 448 bytes.  What is the number of bytes and what is the address range in your case?

I just remembered that there is/was a hardware bug in a different MSP430. Under certain conditions, it mistakenly erases a 64-byte block of certain 512-byte Sector without changing the other 448 bytes.

It is possible that you found another similar bug.

I think you are missing my point.  If the segment FE00-FFFFh gets erased and the update does not complete, the BSL does not run regardless of whether or not it uses interrupts because the reset vector now points to FFFFh, not the BSL entry point.  By never erasing the vector table segment, I am attempting to guarantee that the bootloader will always come up, even after a botched update.  Even if I was using the BSL, I would still protect the vector table segment.

Please do not misinterpret the intent - there is no sharing of ISRs between the bootloader and the main firmware.  The images for the bootloader and the main firmware are completely independent (some shared source at compile time, but nothing at runtime).

I noticed the 16-bytes from DFF0 to DFFFh being erased, but the bytes from DF3A to DFEFh were unused.  I have since filled those unused bytes with A5h to see if indeed anything else gets cleared.  I'm still trying to repeat the problem.

If the 64-byte block from DFC0 to DFFFh were being erased, it would fit the symptoms.  I'll go back through the older 430 family errata to see if I can find any references to similar behavior.

Thanks for your thoughts!

I found it. It is called FLASH16 and is in the new G2xx too. If happens when you try to erase Info-A while it is locked. This is definitely not the cause of what you observed. But it demonstrated that a small part of a segment can be erased without changing the rest of the segment.

My point is, for the 5xx and 6xx, if you put the custom BSL in the BSL-Flash with the right "BSL Protect" procedure, then the BSL can run correctly independent of the contents of Main-Flash, including the reset vector at 0xFFFE and 0xFFFF. You can erase the entire Main Flash, that BSL can still run correctly. You can put trash all over the Main Flash (including 0xFFFE and 0xFFFF), you can still run that BSL correctly.

I tried that with the CC430 and it works fine. I can deliberately make the Application program crash and destroy the reset vector to any garbage value. At the next BOR, I can still use the BSL to restore everything (or load a different new Application). I tried also to deliberately interrupt the RF communication in the middle of critical BSL operation. I can still restart the BSL after BOR. It is like the ROM-based BSL in older chips, except that I can customize it and use any of the available peripheral on the chip. I think this can be duplicated in 55xx using USB instead of RF.

My point is, for the 5xx and 6xx, if you put the custom BSL in the BSL-Flash with the right "BSL Protect" procedure, then the BSL can run correctly independent of the contents of Main-Flash, including the reset vector at 0xFFFE and 0xFFFF. You can erase the entire Main Flash, that BSL can still run correctly. You can put trash all over the Main Flash (including 0xFFFE and 0xFFFF), you can still run that BSL correctly.

I tried that with the CC430 and it works fine. I can deliberately make the Application program crash and destroy the reset vector to any garbage value. At the next BOR, I can still use the BSL to restore everything (or load a different new Application). I tried also to deliberately interrupt the RF communication in the middle of critical BSL operation. I can still restart the BSL after BOR. It is like the ROM-based BSL in older chips, except that I can customize it and use any of the available peripheral on the chip. I think this can be duplicated in 55xx using USB instead of RF.

I apologize.  When initially reading through the documentation for the BSL I mistakenly thought that it was called through the reset vector at FFFEh.  Thank you for straightening me out with respect to that.

During my 1980 junior high school pre-calculus class, we students used Texas Instruments LED calculators. In that same class, I began to complain about hearing people talking about me. Do any of the Texas Instruments products have a history of causing any experiences of auditory and/or visual hallucinations, paranoia, hearing voices and/or hearing people talking about oneself?

Stephen Richards93459 said:

Do any of the Texas Instruments products have a history of causing any experiences of auditory and/or visual hallucinations, paranoia, hearing voices and/or hearing people talking about oneself?

That reminds me of stocking up on Twinkies. Twinkies are very green. It does not require refrigeration and the shelf life is longer than the TI chips. Twinkies are not biodegradable but may be reusable, so it may never need to end up in the garbage dump.