This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EMC / ESD Problems with the MSP430F1xx



Hallo,

 

We have problems with the ESD protection when MSP430F1xx.

This is the + / - 2KV test according to EN61000-6-3.

The device has a switching power supply, wich transform 5-30V DC in to 5V DC

and is protected via Suppression diodes form supply to GND.

Every dataline is also protected with suppressor diodes to Supply and GND.

The signal lines have MOSFETs to convert the values ​​from 3.3V to 5V and

resistance, diode combination for voltage conversion 5V to 3.3V.

After the 2KV burst the MSP430 stops working, it does not respond to interrupts,

it doesn't continue its program code and can not even respond to the Debuggger (MSP FET430 UIF).

When i do a manual reset (on reset pin) it works fine again, but this is not possible by normal product

working.

It is an assembler code. the code has fallout prevention of NMI and OSC. It works with an 4 MHz crystal.

so what i can do?

 

Best regards

T. Keufner

  • Hallo again,

     

    What  I forgot to write, it works fine after a 1500V burst.

     

    Best Regards

    T.Keufner

  • For voltage conversion frmo m5V to 3.3V, you only need a >1k series resistor. All MSP input pins already have clamp diodes to VCC and GND, which can sink 2mA rated current. So for 5V_>3.3V you only need a minimum series resistance that causes a voltage drop of >1.7v on <2mA.

    A fast suppressor diode to GND for ESD protection is a good idea still, as the internal clamp diodes are rather slow. But you don't need diodes to VCC.

    If the MSP doesn't respond after the burst, but recovers after a manual reset, then there isn't much you can do electrically, except using even faster suppressor diodes or with tighter tolerances.
    However, every MSP has a built-in watchdog timer that is made for exactly this case (even though people often think it is for fixing software lockups due to programming bugs). If the MSP doesn't respond anymore, it will restart it after the timeout delay.

    Tip: you can trigger the watchdog in the timer ISR, but only if all vital parts of the applciaiton have reset a counter in time. This relaxes the time between two main thread counter resets, while still providing fast reaction if even the timer ISR isn't exeuted anymore.

  • OK I have found the problem,it is the external oscillator (cristal 4MHz) of the MSP it stop swing by ESD burst, and the MSP OSC-fault could not swing it on or work not correct.

    Best Regards

    T. Keufner

  • Once an oscillator fault happens, this may (if enabled) trigger an interrupt and thesoftware is responsible to clear the fault flags once the oscillator is up again. Until this is done, the internal clock that was run by the crystal is switched to a fallback which may have a different frequency.

    For 1x family, the fallback is only implemented for MCLK. SMCLK and ACLK will simply stop as long as the crystal isn't running. However, if you didn't reprogram the DCO, the MCLK fallback will from 4MHz (your crystal speed) to ~600kHz (default DCO speed). Which may cause some deadlocks in your code.

  • Hallo and thank you for the answer.

    But i have tested it with oscillator fault and it dosent work. The MSP could not swing the osc agian. here is the code I used for it:

    OSC init:

     

    SetupBC     dint                            ; GIE = 1  =>  andere Interrupts sperren

                       bis.b   #XTS,&BCSCTL1           ; LFXT1 = HF XTAL (HF-Modus aktiviert)

                       bis.b   #OFIE,&IE1              ; Enable osc fault interrupt 

     SetupOsc  bic.b   #OFIFG,&IFG1            ; Clear OSC fault flag (Fehleranzeige des Clocks wird

                                                 ; deaktiviert, da in der Anlaufphase der Clock noch nicht

                                                 ; stabil ist und das Fehlerflag gesetzt würde)

                mov.w   #1Fh,R15                ; R15 = Delay (Zeitschleife für die Anlaufphase der Clocks) SetupOsc1   dec.w   R15                     ; -1

                jnz     SetupOsc1

                bit.b   #OFIFG,&IFG1         ; OSC fault flag set? (Überprüfen des Fehleranzeigebits

                                                           ; ob der Clock eingeschwungen ist)

                 jnz     SetupOsc                ; OSC Fault, clear flag again

                bis.b   #SELM_3,&BCSCTL2   ; MCLK = LFXT1 (Der Teiler des HF-Main-Clocks wird auf 1 gesetzt)

                eint                            ; GIE = 1  =>  Interrupts freigeben            

                ret                             ; return from subroutine

     

     

    ;******************************************************************************  

    ;   Only osc fault enabled, R15 used temporarly and not saved

     ;******************************************************************************

     nmi        

    CheckOsc    bic.b   #OFIFG,&IFG1            ; Clear OSC fault flag

                 mov.w   #0FFh,R15               ; R15= Delay

     CheckOsc1   dec.w   R15                     ; Additional delay to ensure start

                 jnz     CheckOsc1               ;

                bit.b   #OFIFG,&IFG1            ; OSC fault flag set?

                 jnz     CheckOsc                ; OSC Fault, clear flag again

                bis.b   #SELM_3,&BCSCTL2         ; MCLK = LFXT1 (Der Teiler des HF-Main-Clocks wird auf 1 gesetzt)

                bis.b   #02h,R11                ; Setze Power-Bit (Spannung vorhanden)

                 bic.b   #04h,R11                ; Löscht das LPM4-Anzeigebit

                bis.b   #OFIE,&IE1              ; re-enable osc fault interrupt            

                 reti                            ; return from interrupt

     

                ORG     0FFFEh                  ; MSP430 RESET Vector

                 DW      Reset                   ;

                 ORG     0FFFCh                  ; NMI vector

                 DW      nmi                 ;

  • Tobias Keufner1 said:
                    bis.b   #OFIE,&IE1              ; Enable osc fault interrupt 

    This should be done after the oscillator is running stable. OFIFG is an NMI and not masked by GIE. So since OFIFG is set on power-up, setting OFIE will instantly trigger an NMI (and is at the same time reset, because there is no other way to mask the NMI and prevent it from interrupting itself: any NMI will reset all related IE bits.)

    Tobias Keufner1 said:
    mov.w   #0FFh,R15               ; R15= Delay

    This delay could be way to short, depending on current MCLK speed. On default power-on DCO speed, this results in a 1ms delay or less.
    The datasheet of the 1611 (the one I use) doesn't tell the worst case minimum frequency for tzhe oscillator fault detection (and therefore the fault timeout time), but it could well be more than one ms. It won't hurt making this delay a bit longer.

    In your main code, you even only use 0x1f, which is definitely way too short.

  • Sorry for my bad English.

    In same applications, as mentioned in IEC61000-4-4, a reset of the device is not tolerable. So it would be interesting to know why the oscillator, or in general the microcontroller, is sensitive and fails to some emc test. In literature I have found some rules to prevent such phenomena like using ground plane, setting unused pin as output if not used and so on. The input pins should be always driven by external circuit but in this latter case:

     - 1 - Are pull-up resitors a good choise to drive input pin when emc is a matter?
     - 2 - And the reset pin of the microcontroller (input with often a pullup resistor) can be the entry gate for the burst to penetrate into the device?

    For example: connecting the reset pin shorted with Vdd I can reach 5500V without any fail, but connecting the reset pin to Vdd using a 2kohm resistor I can't reach 2000V (on the same board with the same circumstances).

  • If there are transients on the the supply line, the input gate, with some parasitic capacitance on the input, detects a relative voltage drop, while it actually was the supply that was going up.
    On static input voltage, let's say, 'high' is detected @ 0,8*VCC. Low is 0.4~VCC. Now a transient comes and raises VCC. If it were a slow rise, in0ut would still be above the threshold and woudl also (through the pull-up) follow the change. But a fast transients like an ESD, may rise VCC withing picoseconds.This will cause effects inside the port logic that may cause the input gate to flip it's state.
    If you read the datasheet chapter about the brownout detector, you'll see similar effects regarding short brownouts or slow voltage rising times.
    One shoudl always keep in mind that while logic might be digital, the physical world and its processes (maybe except quantum effects) are analog. And not instantaneous.
    BTW, the suggestion to switch unused pins to output and always have input pins driven to a logic level is for low-power, not for ESD. Input pins are high-impedance, and when left open, can catch radio waves and start to oscillate. And every input transition or, worse, input voltage near the transition point, causes coem internal current to flow (a static input level nearly draws nothing).
    A GND plane of course helps against ESD. But not always, and can cause othe rproblems (e.g. beneath a crystal, the GND plane should be isolated to the common GDN plane, ecept for one point, so no current will travel across the area beneath the crystal. Also, analog circuitry should have a separate GND path.
    Proper filtering with small capacitors on any supply pin is required to withstand ESD events. In addition to a big one that levels larger supply current changes.
    Tying RST to VCC my cicrumvent (hide) the problem with ESD on the supply. But it will of course inhibit any debug or BSL activity.
    Our devices run on industrial environment, with lots of disturbances, and the 47k/100nF combo on RST does a good job. Also, the code is written to recover from a reset (the startup code detects this and skips initializing important counters). Of course it depends on the application whether reset-aware code can be used. Of course, if the device requires a minute to boot after a reset, and then starts from scratch, this won't be tolerable. But if you're back online after a ferw milliseconds, still knowing the previous state, this will beperfectly okay for the very most applications.

**Attention** This is a public forum