MSP430 Flash Best Practices

From Texas Instruments Embedded Processors Wiki

Flash Corruption - Common Reasons

1. Execution of flash write/erase code within an application (executed intentionally or unintentionally)
2. Accidentally jumping into the bootstrap loader (BSL) ROM code and executing one of the flash write/erase functions there (uncommon, but it has happened before)
3. Low VCC during an intentional execution of flash write/erase
4. Improper flash programming configuration (wrong flash clock rate exceeding cumulative programming time etc )

Software Quality Checklist

1. Ensure proper fFTG (within datasheet specs)
2. Ensure that cumulative flash programming time is not exceeded
3. Ensure programming flash flowchart strictly adheres to User's Guide
4. Check VCC by using SVS or ADC before writing to flash to ensure the programming voltage is within specifications
5. Fill empty code memory space (Ensures that if CPU enters this space, it does not jump off erroneously)
6. Populate all unused interrupt vectors (Ensures to catch unhandled interrupts and prevents CPU from jumping off erroneously)
7. Use watchdog timer to catch erroneous code execution and generate reset (but DON’T clear the WDT inside a periodic Timer ISR!)
8. Fill empty code space
   • Op-code for "jmp $" = 0xFF 0x3F
     • IAR
       • Project --> Options --> Linker --> Processing
       • Check the box "Fill unused code memory"
       • Insert fill pattern 0x3FFF
     • CCSv4
       • Modify the command linker file (.cmd)
       • FLASH : origin = 0x8000, length = 0x7FE0, fill=0x3FFF
   • You can prevent the compiler from using R4 by using the --regvar_r4 compiler option and then write an invalid address to R4. Then write the opcode for CALL @R4 to all your ‘unused’ flash addresses and you will be able to trace the instructions that caused an invalid memory access or catch the access using a Vacant Memory Access Flag VMAIFG, when applicable. See code example: File:Unused memory best practice.zip
9. Populate unused ISR vectors
   • Assign a "trap ISR" to all unused vector locations
   • Double-check the interrupt vector table size and contents with device datasheet
10. Consider storing vital custom application data (calibration data, etc.) in multiple locations. In addition, for non-5xx family members, try to avoid using INFOA for storing custom data to keep the factory-provided data protected.
11. Flash security key usage: consider assembling (or “calculating”) the flash controller access password (“FWKEY”) rather than directly storing( FWKEY ), it in the firmware. This serves as an additional protection against an accidental PC corruption.
12. Check all system clock frequencies with scope
13. Ensure proper DCO speed changing sequence
14. Implement proper XT startup / switch sequences
15. Implement proper XT fault handling
16. Check for nested interrupts. Pay special attention in case NMIs are used.
17. Ensure adequate stack size
18. Ensure SW delays, application variables, etc. are not affected by the compiler optimizer
19. Cross-check applicable device errata
20. Review source code and test firmware thoroughly to eliminate any SW bugs

Please also review application report: “MSP430 Software Coding Techniques” http://www-s.ti.com/sc/techlit/SLAA294

MSP430 Hardware Quality Checklist

1. Ensure VCC is properly decoupled, clean, stable, and within the datasheet parameters at all times.
2. Ensure datasheet “fSYSTEM vs. VCC” curve is not violated at any time. This rule must also be observed during power-up/down ramps.
3. Ensure min. flash programming voltage is met during programming operations
4. Ensure proper pin termination (User’s Guide)
5. Ensure proper XT design and PCB layout
6. Implement adequate ESD/EMI protection

Leave a Comment