MSP430FR5969: handling system resets & reading SYSRSTIV

I suspect that the problem is due to this not really being an interrupt. With a normal interrupt the ISR would be invoked until there were no interrupts pending so that the IV would be zero. The reset vector isn't like that. So events can sit pending in the system and  IV for a long time. There are two ways to clear those: read IV until it is zero or write to it.

I rewrote my reset checking to read SYSRSTIV until 0 because I don't want to clear the register if there is useful info (reset codes) still in there. I see your point about it not exactly being an interrupt but I still can't understand why leaving a value in there was causing so many problems.

Hi,

In the section 1.3.7 of the device User's Guide, it says that "Reading SYSRSTIV, SYSSNIV, SYSUNIV register automatically resets the highest pending interrupt flag of that register. If another interrupt flag is set, another interrupt is immediately generated after servicing the initial interrupt. Writing to the SYSRSTIV, SYSSNIV, SYSUNIV register automatically resets all pending interrupt flags of the group." So it is clear that only the highest priority interrupt could be reset by reading the SYSRSIV, which would leaving the lower priority interrupt flag to be the highest one for handling.

That section is actually part of my confusion. Based on the documentation I found regarding those registers, it seems that they are set after the interrupt occurs and used as a means for the software to determine the cause of a reset after it has happened.

Wei.Jetim Zhao said:

If another interrupt flag is set, another interrupt is immediately generated after servicing the initial interrupt.

This part of the paragraph seems to imply that the value in SYSRSTIV can trigger a reset, which is contrary to the idea that SYSRSTIV is simply used to store the value corresponding to the cause of previous resets.

During an interrupt GIE is cleared and when it is set again, either by the user or a reti instruction, the next pending interrupt is serviced.

There is no equivalent for a reset so those "extra" set values in SYSRSTIV cannot cause another reset. They just hang around to confuse things.

Hi,

The SYSRSTIV is interrupt vector not interrupt flag, which actually trigger an interrupt.

Thanks for the info. However, if a value in the SYSRSTIV register triggers a reset then I don't understand how I was able to run the system "normally" while the register value was nonzero.

When I was debugging this issue (before I changed my code to read the register until zero) I would often find nonzero values in the register despite no resets occurring. How is it possible to have left over values if a value should trigger a reset and then be cleared?

I'm not sure I quite understand what you mean here. Are you saying that GIE is cleared automatically but SYSRSTIV is not?

If that's the case then a value left over in the register could represent a past interrupt that has occurred and not a pending interrupt. Although if that's true, then how does the system know the difference between a stale value and a pending interrupt?

When an interrupt is serviced GIE is cleared. The reti instruction at the end of the ISR will restore the status register and the previous GIE state,which was set. So if there are any pending interrupts, they will be serviced after the reti. Eventually there will be no pending interrupts and the CPU goes on its merry way.

There is no equivalent system for resets. You do not execute a reti instruction or anything like it. SYSRSTIV is a convenience system that lets you avoid polling all of the possible sources of a reset. (Which is a long list.) I can't imagine having two events causing a reset though.

Operation in a typical debugging environment might complicate things. Normally I would expect to see SYSRSTIV = 2 when starting up but the process of updating the code and restarting the CPU is not a power on event. What does that do to SYSRSTIV?

Thank you for the clarification. In my case, I see a 4 after reflashing the board. When I removed the code that reads SYSRSTIV on startup, the value 0x4 is never removed from the register. Even when I induced wdt trips, after resetting, SYSRSTIV still read 0x4. I'm not totally sure how this could have caused the strange behavior I saw, but reading SYSRSTIV definitely fixed the problem.

The lower numbers have higher priority so if that 4 hangs around you will see it after a WDT trip. Reading it again (and again possibly) will eventually get to the WDT.

Yep, that matches my observations during debugging. My question was more about the impact of leaving a value in the register. I was trying to investigate how that might affect the system because I was seeing very strange behavior up until I started reading SYSRSTIV until zero.

Hi,

As I understand, the SYSRSTIV register itself doesn't trigger a reset. It is an interrupt flag which triggers a reset and also change the value of SYSRSTIV to record the interrupt source information. 

Based on the documentation I've read and the answers in here, that is my understanding as well. Unfortunately, I'm still unclear on the impact of leaving an unread value in the SYSRSTIV register. My application was behaving quite abnormally until I added code to read SYSRSTIV until 0 on each startup.