NMI showing up in reset vector?

Hi Jim,

normally no RST should be triggered once you configured the RST/NMI pin as NMI as you described above. Following thing to check.

1. Is the NMI interrupt vector and the corresponding ISR defined and handled correclty

2. Are you sure that the unreliable RST signal is reliable until you define the RST pin to  NMI because if somehting on RST pin happens before a reset is triggered.

Best regards,
Dietmar

1) Yes; NMI triggers correctly, as evidence by toggling an external debug pin tied to a scope

2) Yes; this is happening in 'steady state' condition, with reliable *RST on my desk (i'm dealing with a field condition).  i'm also polling SFRRPCR to see if it changes from the 0xF setting.

Hi Jim,

sorry but I could not 100% follow you last post. So does it mean when you counted 16 NMI that then a the 0x04 (RST pin event) appear if the SYSRSTIV?

Did you ensured that during your intial start-up you read the SYSRSTIV until it is ZERO using something like this below:

//******************************************************************************

//   Functionname: Init_SYSRSTIV

//   Description:  Evaluate the reset vector after a restart.

//

//******************************************************************************

void Init_SYSRSTIV(void)

{

 unsigned int tmp;

 while(1){

   switch (__even_in_range(SYSRSTIV, 0x3E))

   {

     case 0x00:  return;                      //No more Flags      

     case 0x02:{tmp=BOR_Flag;         break;}//BOR

     case 0x04:{tmp=RSTNMI_Flag;      break;}//RSTNMI

     case 0x06:{tmp=OtherRst_Flag;    break;}//PMMSWBOR

     case 0x08:{tmp=OtherRst_Flag;    break;}//LPMx.5 WkUp

     case 0x0A:{tmp=Violation_Flag;   break;}//Security Violation

     case 0x0C:{tmp=SVSL_Flag;        break;}//SVSL BOR

     case 0x0E:{tmp=SVSH_Flag;        break;}//SVSH BOR

     case 0x14:{tmp=OtherRst_Flag;    break;}//SW POR

     case 0x16:{tmp=WDT_Flag;         break;}//WD timeout PUC

     case 0x18:{tmp=Violation_Flag;   break;}//WD PW violation

     case 0x1A:{tmp=Violation_Flag;   break;}//Flash password violation(PUC)

     case 0x1C:{tmp=OtherRst_Flag;    break;}//Reserved

     case 0x1E:{tmp=OtherRst_Flag;    break;}//area fetch

     case 0x20:{tmp=Violation_Flag;   break;}//PMM PW violation

     case 0x22:{tmp=OtherRst_Flag;   break;}//Reserved

     case 0x24:{tmp=OtherRst_Flag;   break;}//Reserved

     case 0x26:{tmp=OtherRst_Flag;   break;}//Reserved

     case 0x28:{tmp=OtherRst_Flag;   break;}//Reserved

     case 0x2A:{tmp=OtherRst_Flag;   break;}//Reserved

     case 0x2C:{tmp=OtherRst_Flag;   break;}//Reserved

     default:  {tmp=OtherRst_Flag;    break;}  

   }

   Set_FaultFlag(tmp);

 }

}

Does this problem appear only on single units or is this a general problem?

Do you struggle with EM noise in the application environment?

Best regards,

Dietmar

No I don't have a loop like that, but i'll take that under consideration.  The example in the user guide does not loop, but the explanatory paragraph does imply it.

Upon further reflection of my test setup on my desk and your example, I suspect that the RST reset is occurring after my intentional one (since it is just noisy and I have no control), and that is what I end up seeing - which is why there were 2 flags indicated in the PMMIFG.  Once I removed my intentional reset, NMI behaved as expected.

We are struggling with EM noise on this pin; caps have been added to RST/NMI and to SBWTCK, although the values may be higher than desired.

Do you have scope shots of the RST and TEST pin while you do this touch experiements would be interesting if any fast spikes might appear on these lines.

Unfortunately, due to the high-energy issues of this setup, especially using a Hi-Pot tester, we can't get scope traces.  10nF has been added to RESET (we have an open question regarding that to another TI person), and no resets are seen there, but i'll see if in the by-hand scenario we can generate something.

When done by hand (simply pulling SBWTCK high by touching a test point), the reset occurs, so there should be no spikes occurring in that scenario.

Jim,

in your test #1 you apply a positive pulse on SBWTCK which couples to RST line

However in test #2 and #3 you apply negative ones? Which amplitude the pulses have?

To attach pictures you have to use rich formatting (right corner of the posting window) and then you can post pictures or attach files.
Would be interested in the scope shots to get a better understanding.

Best regards,

Dietmar

The positive pulse 'by hand' generated some kind of noise coupled back onto the RST line.  When a positive controlled pulse was applied, that did not occur.  We also applied a higher-than-normal pulse on the SBWTCK to simulate the higher energy level (though we kept it 'reasonable').   Green is SBWTCK; Blue is RST, scope probe only on that signal.

Picture attached.

Via separate hardware contact @ Ti, we ended up with 5.6nF cap on the SBWTCK line; 10nF was too much for the TI FET pod & debugger to function.  Also added code for the RST line to change to NMI & ignore the reset.  That code is necessary for deployed units that can't be recalled.  The loop to acquire the reset vector was an interesting twist to the entire problem as well.