MSP4305438 RESET problem

Hi Jens ,

 

Thanks for your kind reply. I would like to give you more observations as we are progressing ......

 

 

 

Jens-Michael Gross said:

One of them is crosstalk to the RST pin. You should have a pullup resistor and pulldown capacitor on this pin. (most 5x devices already have an internal pullup, but some do not have it enabled after power-on, including the 5438. Other families don't have one at all)
The pulldown capacitor is for a safe startup (RST effectively held low while VCC is still rising). It shouldn't be too large if you're using SBW protocol for debugging/programming)

I have a pull up resistor of 10K and capacitor  of 100NF.

 

As per your guidelines I checked the reset vector register SYSRSTIV which read 0x0002 on reset due to unknown reason and on normal start up also it reads the same. Is there any software initialization needed to enable the reset register interrupts in order to read the interrupt status. I am using external 16Mhz crystal and operating MCLK and SMCLK at 16Mhz. Will using the internal oscillator reduce the effect of crosstalk?. How stabl it would be if I use internal oscillator to operate at 16Mhz.

We also tried with connecting the crystal body to ground.

Also for your reference, we checked the state of RST pin on DSO whenever the RESET occurs but the reset pin remains high during this event also. It is clean with no noise as such.

 

Also I am using 2 UARTs for communication. I have initialized both UARTs using PSEL register but since the code is under testing stage we have left the UART's pin unconnected to COM port . Does the UART pins also especially RXD, which is input, should be pulldown internallly if not used even after initializing it as UART pins.???

 

 Regards,

Harshit

harshit said:

I have a pull up resistor of 10K and capacitor  of 100NF.

This should ensure a proper startup and also keep accidental resets caused by crosstalk away.

harshit said:

I checked the reset vector register SYSRSTIV which read 0x0002 on reset due to unknown reason and on normal start up also it reads the same.

SYSRSTIV returns more than one value if you read it several times in a row, starting with the highest piority (0x02) then returning lower priority events.
However, 0x02 means a real,  power-loss brownout reset.

An reset pin caused BOR would return 0x04, security violations would return 0x0a etc. There is no software init required. On power-up, the default value is 0x02.
When teh register is read, the flag for the returned event is cleared, subsequent reads report the nex lower priority event (after a power-up, the re is none), until all event flags are cleared. A write immediately clears all event flags, subsequent reads return 0 until a new reset happens.

So it seems that somehow the brownout circuit is triggered.
There may be two reasons: either VCC is dropping below the threshold voltage of 1.55V(max) for some time (<1µs), or the core voltage drops below 0.83V.

About VCC, well, I cannot do anything. That's your job. Just ensure that there is enough capacitance to cover all imediately current needs.
For the core voltage, the MSP has a separate VCore pin that requires special care. This is not an output or input pin,  its purpose is to give a point to add a capacitance for stabilizing the internal VCore voltage, which cannot be provided on-chip for this size. A 470nF ceramic capacitor (typ.) is required to DVSS.
The capacitance between DVCC and DVSS should be at least 10 times larger and may be split across the four DVCC pins. If you use electrolytic capacitors on DVCC, you should at least add one 470nF ceramic for a low ESR.

For the AVCC pin, it has proven useful to put a 10 Ohm series resistor between DVCC and AVCC, and add a 10µF tantalum and 100nF ceramic capacitor between AVCC and AVSS.

harshit said:

we have left the UART's pin unconnected to COM port

You really shouldn't direclty connect these pins to a COM port. COM ports have RS232 voltage levels (-+3..15V) while the MSP requires 0V/VCC. You need a level shifter (MAX232 and derivates).
If you have attached such a chip, the UART input is no longer open, as it is always driven by the chip.

However, open inputs should be stuffed with a pulldown (47-100k) for lowest power consumption. The internal port pulldown should do it (but it is not available during I2C operation on the 5438.)
But other than power consumption, it should have no other influence..

 

HI Jens....

Thanks once again

Jens-Michael Gross said:

So it seems that somehow the brownout circuit is triggered.
There may be two reasons: either VCC is dropping below the threshold voltage of 1.55V(max) for some time (<1µs), or the core voltage drops below 0.83V.

 

Yes you are right. We monitored the activity of pin Vcore whenever the reset occurs. We observed that for a duration of 200ns it dropped below 1V which was normally (1.8V). We even tried to test the same by using SVMOUT pin ands etting SVSLOE bit and the corresponding interrupt in order to further ensure the cause, but the SVMOUT pin never went high on getting an inteerupt due to voltage level supervision going low below threshold level. I wrote the following code:-

Also capacitor (470nf) is not routed directly to the VCORE pin, so layout issue.

void main(void)
{
    unsigned int i;
 
      WDTCTL = WDTPW + WDTHOLD;               // Stop watchdog timer to prevent time out reset 
   
    PMMCTL0_H = 0xA5;                        //open PMM module
    SVSMIO |= SVMLOE;
       PMMIFG |= SVMLIFG;
    SVMOUT_PIN_SEL =1;           
       SVMOUT_PIN_DIR =1;   
    PMMCTL0_H = 0x00;                        //lock PMM module

//--------------------osciilator init --------------------------------------------------------------
 
 
  
      XT2IN_PIN_SEL     = 1;                    // configure for XT2 crystal
     XT2OUT_PIN_SEL     = 1;        
    UCSCTL6 &= ~XT2OFF;                       // 16MHz oscillator on
    UCSCTL3 |= SELREF_2;                     // FLLref = REFO,necessary as XT1 not present
    UCSCTL4 |= SELA_2;                         // ACLK = REFO,necessary as XT1 not present

If we ensure that the cause of  reset is SVS module. Is there any method to shut down the supervision or supply monitoring to avoid the unwanted reset as of now. Will this cause undesirable effect.

 

Thanks and regards,

Harshit

harshit said:

... If we ensure that the cause of  reset is SVS module. Is there any method to shut down the supervision or supply monitoring to avoid the unwanted reset as of now. Will this cause undesirable effect. ...

If you keep falling to a safety net, do not remove the net.

harshit said:

We observed that for a duration of 200ns it dropped below 1V

This will in any case crash the CPU core without a chance to recover. It might even corrupt the ram content. So it's intentional and required that the BOR is triggered.
The SVS won't help you. If the voltage is too low to operate, no interrupt can be executed.

Trying to solve the problem in software is like saying "give me a call when you're dead".

You need to figure out why VCC is dropping, and remove the cause. That's your only option.

Hi Jens

 

Jens-Michael Gross said:

Trying to solve the problem in software is like saying "give me a call when you're dead".

You need to figure out why VCC is dropping, and remove the cause. That's your only option.

 

Thanks once again . I truly agree with you. I would like to inform you that with constant support from local TI personnels and based on their feedback we switched to internal DCO instead of using external XT2 16Mhz crystal. The moment we did this the processor now works properly as desired with no unwanted resets.

It seems that the radiated noise due to contactor arching disturbed the high frequency oscillations which might be causing the reset. I would like to know your point of view on this.

But the above solution gave rise to new problem. The VFD (16X2) display which was working on port pins earlier did not function at all when we switched to DCO and it works fine with external crystal enabled. Also the same code works fine with both DCO and external while using 16x2 LCD displays  . The VFD sources more power from supply compared to normal displays at start up, which was our observation. By changing the power supply with high current rating solved the above issue as well.

I need your point of opinion on above observations as well to identify the cause.

 

Thanks and regards,

Harshit

 

 

harshit said:

It seems that the radiated noise due to contactor arching disturbed the high frequency oscillations which might be causing the reset.

Well, if this were the case, I don't understand why you were seeing brownouts on VCC. It has nothing to do with the oscillation.

In fact, if the oscillator stops for some reason (and yes, the contactor could influence it, especially if the design doesn't provide enough protection against crosstalk by shilding the oscillator and its wiring), there are only two possible effects:
either the crystal stops. This wold cause the CPU to fallback to the DCO. No harm done and no reset. An oscillator fault NMI could be used to detect this and to switch the CPU mack to the crystal once it is stable again)
or the crystal produces glitches which cause the CPU to run far beyond specification for one or two cycles. This would crash the CPU and eventually trigger the watchdog (if enabled). But then there would be too no brownout reset. The watchdog reset could be identified by checking the WDTIFG bit after program start (after a power-on/brownout it is clear, after a WDT trigger it is set) or through the reset vector register (whcih didn't indicate a watchdog reset).

harshit said:

The VFD (16X2) display which was working on port pins earlier did not function at all when we switched to DCO and it works fine with external crystal enabled.

This could be a racing condition. With the crystal, you were probably waiting for the crystal to come up. So the display had enough time to power-up even with the low-current supply. With DCO, which has no swing-in, you were accessing the display now before it was ready.

I can even imagine that it was the display that did reset due to the contactor, and then has drawn anothe rhigh initial current burst when restarting, causing a brownout on the MSP VCC (I don't know your circuitry, so this is just a wild guess).