Watchdog key violation sets SYSRSTIV=SVSL ans SYSRSTIV=SVSH

Hi Markus,

Just fyi -- TI has changed the User's Guide to show that indeed PMMRIE=0x1100 is the intended initial value for this register.  They did an incomplete job of updating the User's Guide though.  The summary table of all the PMM registers still shows an initial value of 0000h.  All the newer x5xx products initialize PMMRIE to 0x1100, too.  Yet another case of confusing documentation I'm afraid.

I have one idea.  Be sure you clear all sources of reset by writing to the SYSRSTIV register.  It shows you only the "highest" priority reset cause at a given time.  When you read SYSRSTIV, it clears that highest priority item and then shows you the next one.  And so on.  Writing to SYSRSTIV is a magic way of clearing them all.

I have this code in my reset handler after using SYSRSTIV to determine the cause of the reset.

SYSRSTIV = 0;  // be sure we can determine the correct cause of the _next_ reset

Jeff

Jeff Tenney said:

I have one idea.  Be sure you clear all sources of reset by writing to the SYSRSTIV register.  It shows you only the "highest" priority reset cause at a given time.  When you read SYSRSTIV, it clears that highest priority item and then shows you the next one.  And so on.  Writing to SYSRSTIV is a magic way of clearing them all.

what I did was something like

do {
    rst = SYSRSTIV;
    print(rst);
} while (rst != 0);

This does effectively the same as writing SYSRSTIV to 0. But anyway, I tried out what you suggested and it didn't change anything. I still get a 0cc, 0xe, 0x0 sequence instead of just the watchog key violation when subsequently reading SYSRSTIV. What I don´t understand is what the voltage supervisor has to do with the watchdog.

Markus

Markus said:

What I don´t understand is what the voltage supervisor has to do with the watchdog.

Absolutely nothing.  I use the '5438 too, and I use the wd key violation sometimes.  It works.  But I don't disable the supervisors in my app.

I'll try to reproduce your issue later today.  Just so you'll know you're not completely crazy.

Jeff

Markus,

By turning off the supervisors (SVSMHCTL = 0 and SVSMLCTL = 0), I get the exact same behavior you get.  SVSH and SVSL causes for reset plus no indication of a watchdog key violation.  Same results for flash key violation.  [Editing note: I had some wrong information here before.  I have deleted it to avoid confusing anyone.]

Looks like somebody at TI better look into this one.

Jeff

Jeff Tenney said:

From the User's Guide I see that a PUC (as in a key violation) causes the SVSHE and SVSLE bits to be set.  In your case the supervisor circuitry has not been "up" because you had the supervisors off.

Excellent catch.

What happens if you switch the supervisors on again manually, after they have been off for some time? A POR too?
If you're right with this glitch (and I soppose so, as you seem to have more time than I for testing thing on your real MSP), this is something for the errata sheet.

Personally, I'd prefer if a POR wouldn't clear the the other reset flags - everything except a BOR should leave them untouched.
I too don't like the fact that an SVS reset does not reset the SVS configuration to default (after a BOR, it would be default anyway, so the software needs to cope with it und er all circumstances). It prevents the device from doing anything as long as a user-defined SVS condition persists.

This was especially true for the 1X series, where you had to raise the SVS limit if you wanted to clock the MSP with full speed, while it was working perfectly at default speed with the default SVS settings - and signal the too-low voltage. Instead, it would be held in reset state until the voltage was high enough again for fullspeed operation.

Jeff,

thanks for your effort in investigating this issue, it's nice to know that I'm not the stupid idiot who can't read a user guide.

As you mentioned, one solution is to just leave the supervisors on. The second solution is to set PMMRIE=0 when disabling the supervisors (see my first post within this thread).

Markus

You're right.  (Duh!)

The best workaround is just to set PMMRIE=0.  I completely forgot about it.

It makes for a good rule.  If you disable a supervisor, be sure to clear its SVSxPE bit in PMMRIE (best done before disabling the supervisor).

Jeff

Jeff Tenney said:

The best workaround is just to set PMMRIE=0.  I completely forgot about it.

It's easy to forget which bits are set when, especially if in a different register. Most people never even noticed the subtle differences between 0, (0), [0] and {0} in a register description. This happens because nobody reads a preface section in a manual if it begins with 'about this manual' and 'FCC warning', even if later the glossary follows with such important information.

The bits in PMMRIE are only set on a BOR (including SWBOR). So if you clear the SCSxPE bits and the supervisors, and then set the PMMSWBOR bit, you'll still see the SVS resets. By setting PMMSWPOR or any other POR/PUC generating reset source, you won't.

Wow can things get complicated for such a simple topic :)