MSP430F2274: Interrupt vector changes during operation & causes system boot fail

Hi Eduard,

There is no operations in the device to write the interrupt vector area at flash.

By the way, not very clear about the issue details, does that mean the interrupt vector in the flash is changed? 

Hi Gary

Yes, somehow the interrupt vector has changed in different ways in different cards

See below, working MCU vs three failed:

What can cause that ?

Any advise how to investigate this ?

Do you have any flash operations in your application code?

By the way, what's the failure rate?

Dose this project under production or evaluation status?

Hi Gary

There are cyclic writes to Flash 256-byte Information Memory.
The areas where the address is used are:
ADDR_FLASH_SEG_B (0x1080)
ADDR_FLASH_SEG_C (0x1040)
ADDR_FLASH_SEG_D (0x1000)

The failure rate is Approx 5% (currently)

The project is in production, more than 5K systems already in the field

What can cause the interrupt vector to be changed ?

You can refer to this document 

https://www.ti.com/lit/an/slaa729a/slaa729a.pdf?ts=1671108404259 

Please check the item in the table 1 one by one with your using case to see if any hints there.

Will do, Thanks

Nothing to hint the problem we facing...

Anything else that could write/change the interrupt vector besides application code ?

Hi Eduard,

One question here that the flash changing part always be the interrupt vector besides application code?

If so, it seems more related with software. You can try to increase the stack size that to avoid the overflow of the stack that will not detected by the compiler. 

Investigation depends on your code since that is almost certainly at fault. Details of the code that does the writing and how it is called would help.

If the flash write code is a function which is called with an address to write to, add sanity checks on the address before writing.

Your failure examples show different types of failures:

1) Only the reset vector has changed. There are two ways this could happen. You code code copy the segment to be erased into RAM, erase the segment, then write back the saved data along with your changes. The other is to perform a single word write without erasing the segment. Erasing changes all bits to 1 while writing can convert 1s to 0s.

2) Looks like a segment erase happened with no writes.

3) Perhaps a failed segment erase due to incorrect flash timing generator settings.

All suggest execution of your flash write code with bad data. Perhaps because some other failure (mangled stack) has resulted in execution running wild.

Thanks Gary

We are on it

Thanks David

We'll take your recommendation and review the code

OK, feedback to us, if any progress on your side. Thanks