Why mcu not reset on ESD test ?

[Mahendra Rana]

Posted on May 16, 2018 at 08:54

1. When I run system clock through HSE(8MHz/24MHz/25MHz) and PLLCLK (multiplier PLLN and divider PLLM & PLLR) than mcu not reset by ESD.

2. But when I run system clock directly through HSE(8MHz/24MHz/25MHz) than mcu get reset by ESD.

Can any one comment for my issue..

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Imen.D]

Posted on May 16, 2018 at 11:36

Hello

Rana.Mahendra_Singh

,

What is the Hardware board used ?

Best Regards

Imen

[Mahendra Rana]

Posted on May 16, 2018 at 14:01

That board is not any nucleo board. Its circuit and pcb was designed by our own.

[Tesla DeLorean]

Posted on May 16, 2018 at 14:06

Ok, but this provides zero insight, to social cue here is to provide sufficient detail that someone not inside your head can understand/see what is going on.

Present your question with enough context that it might be reviewed.

Not sure how HSE vs HSE+PLL would behave materially differently in the current context. Is a reset response to a large ESD not a likely/acceptable outcome?

[Mahendra Rana]

Posted on May 16, 2018 at 12:47

Board is design by our own

[Tesla DeLorean]

Posted on May 16, 2018 at 13:55

>>Board is design by our own 

That's really not very illuminating.

The cue here is to provide more clear and specific information about the system that has a problem.

[AvaTar]

Posted on May 16, 2018 at 14:08

The cue here is to provide more clear and specific information about the system that has a problem.

And what is the problem at all.

At least for burst/surge tests which are required for commercial devices here, the DUT is allowed to stop operating during the test. It only must not sustain permanent damage.

[Oliver Sedlacek]

Posted on May 17, 2018 at 10:22

If you can find the reset cause it would help. It will be in a register somewhere. A possible explanation is that the ESD upsets the crystal oscillator, which does contain a sensitive high frequency amplifier. If the oscillator stops oscillating for a while the MCU will detect a 'loss of clock' which may reset the MCU.

[AvaTar]

Posted on May 17, 2018 at 11:17

A possible explanation is that the ESD upsets the crystal oscillator, which does contain a sensitive high frequency amplifier. If the oscillator stops oscillating for a while the MCU will detect a 'loss of clock' which may reset the MCU.

In theory, this should apply to both cases, independant of the PLL.

[Oliver Sedlacek]

Posted on May 17, 2018 at 13:14

The crystal oscillator will be more susceptible to ESD than the internal RC oscillator because its signals are exposed outside the chip package, providing a much bigger pickup area.

[Daniel O'Neill]

Posted on May 17, 2018 at 11:44

Hi,

This sounds like an interesting behavior. The theory I have is that the ESD is causing a glitch on the HSE that causes a reset. To debug this further would can look at the register that tells you what reset you (RCC_CSR on STM32F4) What does this indicate as the reset source?

As a further step you can program the interrupts for the hard fault etc to go to a specific location and set a flag that you can check.

As to why the HSE+PLL doesn't reset, my theory is that the PLL is effectively buffering the glitch on the HSE.

The PLL is usually some sort of VCO (voltage controlled oscillator) whose output is compared to the input from the HSE and then its control signal is adjusted. VCOs have a lot of parameters but I would imagine that noise rejection would be an important one.

Also for performance and stability they likely have a low pass filter on the response from the comparison of the output and the input which should provide the noise rejection.

Note that enabling the PLL on one unit may pass the ESD test but on another it may fail. To fix it rather than mask it I would suggest that you look at the path the ESD current may take. Could it go anywhere near the HSE source (I assume a crystal)?

[Mahendra Rana]

Posted on May 18, 2018 at 19:43

what in Hard fault handler I have to write. Can you elaborate more please.. 

And one more interesting thing is that by default in HAL library all 

fault 

interrupt handler routine having infinite while loop than at that time MCU reset during esd test and got hangs. But when I called system soft reset than only mcu not hangs. and restart.

as in below code mcu not hangs when auto reset by esd otherwise sometimes it goes into this anyone handler and got hangs in infinite loop so I wrote in all handler as system soft reset in spite of infinite while loop only. But I don't now that in which handler it got hangs. So is it a right way??

I will do some more trials to find exact location and handler in which it goes after auto reset by esd.

void HardFault_Handler(void)

{

NVIC_SystemReset();

}

void MemManage_Handler(void)

{

NVIC_SystemReset();

}

void BusFault_Handler(void)

{

NVIC_SystemReset();

}

void UsageFault_Handler(void)

{

NVIC_SystemReset();

}

[Daniel O'Neill]

Posted on May 20, 2018 at 23:54

I would do as

Turvey.Clive.002

‌ suggested. Identify an unused portion of RAM and write a different number to it before calling NVIC_SystemReset() in each of the cases in the code.

Alternatively you could replace the call to

NVIC_SystemReset() with a while() loop doing nothing. Then after an ESD zap connect with debugger and see where the PC counter is. Just be aware of the optimizer combining bits of code.

[Ran Kai]

Posted on May 24, 2018 at 12:58

One thing you could try if you have the MCO (master clock output) pin available on your board you can see what's happening on your oscilloscope during the ESD event when using PLL and compare it with without PLL.