NRST low + HSE source gone = system freeze instead of reset

[TDK]

Posted on March 11, 2016 at 03:09

I have two chips, a master and a slave, both STM32F429.  The master is using the internal HSI as a PLL clock source.  The master is outputting a 16 MHz signal that the slave is using as a PLL clock source through HSE bypass.

The NRST lines of both chips are tied together and when I pull NRST low for 100ms, I expect a system reset on both chips, with both of them booting up nicely afterwards.  What I'm actually seeing is the master chip boot up just fine, but the slave chip gets stuck and fails to boot up.  By this I mean that it stops doing what it was doign (blinking LEDs among other things) and also fails to boot up (which I notice by the LEDs not blinking), even when the HSE clock source is present again.I assume that taking away the HSE clock source at the same time I'm pulling NRST low is causing the hangout here.  I've noticed that holding NRST low for ~2 seconds causes things to boot up just fine.So, some questions:Is there anywhere in the RM or ANs that discuss this, specifically if stopping the HSE source is okay or not?  And is the improvised solution (holding NRST low for longer) guaranteed to work?  Or can I fix the circuit without additional circuitry somehow?Or Is there anything I can do in software to have a failsafe if the HSE source disappears?Obviously I could have an external clock source that isn't interrupted by the NRST process.  Or I could tie NRST to the power supply such that NRST low causes the power to be cut to the chip as well, presumably triggering a reset.Thanks.

[Tesla DeLorean]

Posted on March 11, 2016 at 03:24

I assume that taking away the HSE clock source at the same time I'm pulling NRST low is causing the hangout here.

I'm far from convinced here. In bypass mode you have no perception if the HSE input is valid or not. So you'll have issues starting the PLL, waiting for it to lock, or waiting to switch to it. Check for unbounded while() loops, and exit/fail-over paths. You need to move your diagnostic output, either LED, or USART, to right before SystemInit() and main() are called, and be absolutely certain the part isn't actually starting, vs jamming up in your own code. The processor starts from HSI, so HSE should be irrelevant here. A 100ms down stroke of NRST should be sufficient, but this must be done with a OD driver.

[TDK]

Posted on March 11, 2016 at 04:51

Hmm, thanks for the notes.

I do use UART as the primary debug channel, and there isn't any output generated when the system hangs.  So I know it's not still executing, and that it hasn't booted up correctly either.  It's in limbo somewhere.  But yes, it would be good to be 100% sure of this.  I could also try the reset without disabling the HSE source to yield more evidence.Looks like I failed to mention that the master chip has no such reset issues, only the slave chip.  And only if it's currently using the HSE bypass.  If I switch it to use its own internal HSI instead, the problem disappears.The switch from HSI to HSE is done well after boot, and if the HSE source isn't present, it's smart enough to figure that out and say so over the debug channel.I'll post more if I find anything useful.

[Tesla DeLorean]

Posted on March 11, 2016 at 05:26

Somehow I think your diagnostic code is deeper into the execution path than I'd have it. I would uses some tight assembler code right at the Reset_Handler, as toggling an LED in main() is a bit late. ie something in the first 10-20 instructions the processor executes while running from HSI

If you remove the call to SystemInit() in startup_stm32f4xx.s the CPU would just run from HSI

[waclawek.jan]

Posted on March 11, 2016 at 08:59

Intriguing.

Do you switch off HSI after switching to HSE/PLL? Did you try to experiment with CSS? JW

[TDK]

Posted on March 11, 2016 at 19:02

Yes, I did switch off the HSI.  But I just did a test now with it still enabled and the results were the same.

I had no idea CSS (Clock security system) was a thing, but after looking it up it seems exactly like what I need!  Thanks, I'll experiment with that.

[TDK]

Posted on March 12, 2016 at 00:40

Hrmm.

I've enabled CSS and in the CSS handler, I simply do a system reset. I've verified this works fine by disabling the HSE clock source during operation and watching the slave chip reset. Perfect, right? Here's the code. (I know everyone hates HAL, but it's really not that bad.)

// enable the CSS to trigger when HSE disappears
...
HAL_RCC_EnableCSS();
...
// handler for Non-maskable interrupts
void
NMI_Handler(
void
) {
HAL_RCC_NMI_IRQHandler();
}
// this gets called when the HSE source disappears
void
HAL_RCC_CSSCallback(
void
) {
// reboot!
HAL_NVIC_SystemReset();
}

However, the original problem still remains! If I reset the master at the same time as the slave, the system still gets hung, even with the CSS enabled. So what I'm going to do is put a passive RC circuit such that the slave gets reset slightly (several microseconds) after the master. I've tested this out and it works. I would've preferred a software solution but I'm not sure what else to try really. Obviously for this to work the CSS needs to be enabled. Probably don't need to actually handle the interrupt though.

[waclawek.jan]

Hi @TDK ,

I know this thread is a tad bit older, but can you please tell us what was the end of this story?

Thanks,

Jan

[TDK]

@waclawek.jan I had to look this one up. It looks like I just put the RC circuit (1kOhm, 0.1uF) on the NRST pin of the slave and everything worked okay. Wish I had more insight to give, but that's all I can recall. This was on a project that didn't have much activity after this post.

[waclawek.jan]

Hi @TDK ,

Understand. Thanks for the info.

Jan