• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 80 subscribers
  • Views 823 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430 F5528 INFOD Flash Erasure after X Number of Power Cycles

Jordan Meyer
Prodigy 160 points
Other Parts Discussed in Thread: MSP430F5528

We have two custom PCB utilizing the MSP430F5528 with 128K Flash.  Both boards use a custom bootloader that reads keys from INFOD upon boot up.  IF the keys are valid then the application code (board specific code) is loaded.  If the keys indicate FW update then the board waits for update sequence.  Otherwise, the boards are initialized as a default boot device and no longer function since application code is not loaded.

Consistently I can cause the INFOD section of Flash to be erased by cycling the power to the board between 5 and 100 times at a rate of about 3-5 power cycles per second.  The issue has also been observed during the normal use age of the boards, where they are functioning as designed within a system and after power is cycled (due to necessary reboot or mechanical obstruction) the boards with MSP430F5528 have their INFOD section erased and stay in boot code. 

I have enabled the LOCKINFO key on the flash controller and programmed the SVS/SVM to perform POR if Dvcc or VCore is too low but nothing seems to fix the issue. 

We are using the DCO configured to ~8MHz and system timers at DCO/2.  The only time the boards read the INFOD sections are on startup and if a FW Update is initiated the INFOD is erased and new values are written.

What else could be causing this issue?

  • 0
    TI__Expert 7125 points

    Jordan,

    Looking through your code (received from Mike Pridgen) I would first suggest replacing your PMM code with calls to the HAL libraries to set up SVS/SVM. This is imperative as many customers attempt to use the PMM/UCS by directly accessing registers and experience problems. These registers are very tricky to use and we do NOT recommend people code by directly using these registers. That is why we developed the HAL libraries. The code and descriptions of the corresponding functions is found here:

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

    Are you sure that between the "3-5 power cycles per second" and code is being run on the MSP430 at all? It is very possible that you are removing power before the SVS can be configured. 200-300 ms could easily pass before the SVS is fully configured, particularly if you are not using a crystal. Does your custom board use a crystal? You can decrease the amount of time it takes for startup by placing __no_init in front of large variable declarations.

    I would recommend that you test somehow that the SVS has been fully configured before a reset occurs. Also, is it possible that the reset occurs right after InfoD is erased by your application before it gets rewritten?

    Also, in your emails with Mike Pridgen it appeared that all of Info Memory was sometimes corrupted. Have you narrowed that down to only InfoD being corrupted? Or are you still experiencing flash corruption at other locations?

  • 0 in reply to MikeS
    Prodigy 160 points

    Thanks for your suggestions. I was finally able to trace down the issue with INFOD. In our application the BSL uses infoD to determine if there is a valid application or if a firmware update was requested. If neither condition is met then the board is initialized as a generic boot device. After updating the firmware, the BSL copies the correct values from the application code into INFOD and then launches the application. Under normal operating conditions, INFOD and the application data will match and the code will load as desired.

    However, I found that after the application code has started, there was a call in the Init Hardware function to verify the contents of INFOD. If any discrepancy exists (even one byte is wrong) then INFOD would be erased and restored to the correct values. The function to verify InfoD loops through all 80 bytes of infoD and compares them to the 80 bytes in the application data. In testing, if even a single byte is off in INFOD then it was erased and then restored but due to the power cycling, it was never properly restored and the board no longer boots. Running the original code, I could get a MSP-TS430RGC64USB/MSP430F5528 target board to fail in as few as 5 power cycles. After commenting out the line of code, I have yet to see it fail. I also determined that this verification was unnecessary because we are only checking two locations within INFOD for a valid application and it wouldn’t really matter if any other values in INFOD were not right. Removing this also helps save on read/write cycles to INFOD.

    I was able to trace this down by using the method suggested where a flag is written to a different section of flash (INFOB for my test) and a different value was written at various points throughout the firmware. The first value written to 0x1900 was written right before the application loaded. Then I offset subsequent values to determine how far the firmware got before INFOD was erased. This allowed me to determine which function(s) were causing the issue.

    Throughout the process I also tried a few other options that we will carry forward to our revised edition of the BSL. For example, one attempt I tried was removing the Flash Control password from our FlashErase and Flashwrite functions and instead storing it in RAM. Each time the flash erase or write was called, the ram location was updated to the correct password (FWKEY = 0xA500). After the flash function exits, I would invalidate the ram to 0x0000. That way if the erase function did get erroneously called, the flash password would be invalid and the processor would force a reset. This helped me determine that the processor was not erroneously jumping to the flash erase function and also explained why other attempts such as the PMM, ISR traps, and filling unused flash did not help.

    Thank you for all your help in this issue.

**Attention** This is a public forum