MSP430F6438 SYSRSTIV register

1) I doubt that.  Instead, I would guess the FET merely cleans up after itself after performing a debug reset.

2) I don't know.  The DOPOR would work nicely as it keeps the FET connection active (unlike DOBOR).

3) You can read "all" causes of reset by continuing to read SYSRSTIV repeatedly until you read zero.  Yes there can be multiple causes of reset; like during power up SYSRSTIV_BOR occurs and also SYSRSTIV_RSTNMI in your circuit.  Those are two causes of reset, and SYSRSTIV gives you only the highest priority one.  If you read SYSRSTIV twice in this case, you would read SYSRSTIV_BOR followed by SYSRSTIV_RSTNMI.  Note that if you don't care about any more of the lower priority causes of reset, you can *write* to SYSRSTIV to clear all remaining cause indications.

4) Doubt it is spurious.  You cannot disable the BOR.  You can, however, disable the SVS which is a different supervisor entirely.

Jeff

Peter Clerico said:

1) Is it true that the FET causing a processor Reset does not set a value in SYSRSTIV register (i.e. the value is zero)?

Not if the FET is really performing a reset. However, if you debug and have the register view showing you the SYSRSTIV register, reading it for display will clear its content the same way as reading it in your code.
Also, see 2)

Peter Clerico said:

2)  If the FET doesn't set any Reset bits, what does it do to cause a Reset?  (This may be important to understanding how registers are reset during debug)

It's possible that the FET is jsut instructed to set the PC to the reset vector. This isn't a real reset, even though it initializes your program. It would not, however, initialize the hardware modules. It's rather a 'restart program' than a 'reset device' then.

Peter Clerico said:

3) The SYSRSTIV register is only read once per reset, which gives one reset vector.  Is it possible for there to be more than one source of a reset?  How?

The SYSRSTIV register is more a priority encoder with a bitfield of reset causes attached. Each time you read SYSRSTIV, it returns a number that correlates to the highest bit set in this bitfield, while at the same time clearing this bit.
So each read of SYSRSTIV returns one reset cause since last reading the register. But only once per type (so you don't know whether there were one or 100 watchdog resets) and not necessarily in the order they happened (but in order of priority).

Assuming you have a brownout reset (power-on) and before you did to read SYSRSTIV, you got a watchdog reset too, and another one (because you forgot to kick the watchdog while waiting for the crystals and the first two times the crystals were coming up slowly) then first read will report the watchdog reset (but only once!), second the brownout reset (which has lower priority) and the third read will report 0.

Peter Clerico said:

4) Any thoughts as to why a spurious BOR value from the SYSRSTIV register is occurring?

Maybe the MSPs brownout detection is more sensitive than your external controller?

Guys,

Thanks for the responses.  I have indicated these to my customer; will advise any furhter concerns.