A couple days ago I stumbled across and diagnosed CPU42 (DINT immediately after EINT crashes the CPU if an interrupt is pending - this instruction sequence can happen from C code when the compiler inlines functions). Then I found a post where it was reported two years ago and learned its name. http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/53319/832795.aspx The comments and bug-database imply that the fix may not be adequate for two reasons:
1) One commenter reported that, depending on the instruction, the CPU can execute one _or two_ instructions after EINT when an interrupt is pending.
2) The silicon-errata=CPU42 is described as not being turned on by default.
Reading the threads here gives me a non-warm-and-fuzzy feeling about CPU errata. For one thing, CPU42 apparently didn't make it into the toolchain until 4.1.3, although it was reported in June 2010. For another, there are various bugs being reported where other CPU errata are not supported - at all - even by 4.1.3.
And CPU42 is not in the errata sheet for the processor I'm using (MSP430F5438A) that I downloaded yesterday.
It was literally a one-in-1000 chance that this bug cropped up repeatably rather than randomly crashing the CPU once every few days. If the timer-tick interrupt hadn't fallen right on the correct spot in the initialization code... ugh. We would not have caught it until it was too late.
So, we have to ship this product in a couple of weeks, and it'll be impossible to change the code after that. (It's actually a CubeSat.) Given how close this came to killing us, I want to make very sure that there aren't any other known-but-poorly-documented errata lurking, and that all known errata are actually dealt with correctly by our toolchain/environment.
I'm installing the latest CCSV5 right now (I'd been using toolchain 4.1.1, which is not that old). What else should I be doing? Where else should I be reading? I don't have the time (or the budget) to read every post in these forums, or every bug in the database, in case it contains a bug that might affect my chip.
Do I just _hope_ that there aren't any more problems? How do other MSP430 engineers handle this? Does anyone have any advice I can use?
Many thanks!
(BTW, if any TI engineers are reading this, _please_ document the DCO/FLL sensitivity to power supply fluctuations in more detail. We found that a 50 mV 1 us spike would change the master-clock timing enough to cause serial bit errors. Even after we'd debugged and characterized the problem, our hardware team claimed their power supply was good enough - and we couldn't prove them wrong, because I can't find anywhere that you describe the requirements for the power supply.)