Determining where STM32F417 was when it reset by IWDG?

[daqq]

Hi guys,

I'm dealing with a problem - a processor (STM32F417) in a system gets stuck and the watchdog kills it... somewhere. Due to various reasons I can't have a debugger connected to the device while it's running. Do you know of any way that would allow me to see at least where the program counter was when the last reset occured? Ideally there would be some kind of PC_POSITION_AT_LAST_RESET register.

I'm confident that it's the watchdog doing the reseting - the appropriate bits in the RCC CSR register are set (IWDGRSTF and PINRSTF) are set (I store them, show them and reset them, so I don't accumulate them as time goes on). The watchdog is set to go off after about 0.9 seconds of not being reset. It is reset in the main loop.

The system does have pretty high pulses in it and the reset does happen (only, but not always) during those pulses - as such it could be some electrical interference causing... something?

Disabling the watchdog caused the system to get stuck during the pulses - and I have no idea where the system gets stuck. At the moment I'm trying various ways to narrow down the place where it freezes, but it's a pretty nasty bit of code, so it might take some time...

Any ideas?

Thanks,

David

[daqq]

OK, the bastard apparently goes into the Hard Fault exception handler. Damn. Some EMI exorcising is needed probably...

[Brutte]

The independent watchdog reset won't force the core to go into hard fault. However, jumping into hard fault and waiting there doing nothing with watchdog downcountig will trigger a watchdog eventually.

AFAIK independent watchdog does not have interrupt capability but you can run some other raw timer or window watchdog instead - just for tests. Substitute the code for clearing independent watchdog by the code that reloads a timer. Enable interrupts and final effect should be similar but easier to catch..

[daqq]

Thanks for the info.

I've done something similar to that, it seems the interference is very bad. The CPU just does random things during the pulse. Once it had a IMPRECISERR, another time there was the UNDEFINSTR.

So it's some heavy interference.

[Brutte]

Once it had a IMPRECISERR, another time there was the UNDEFINSTR.

As stated - watchdog reset cannot force a core enter hardfault - you cannot even configure watchdog to do that.

My conclusion is that your issue is not watchdog related (consider changing the topic name to attract audience).
Once you disable watchdog only (without any changes to memory map) - does the core enter hardfault just like before? I would expect so.
IMHO watchdog triggers just because you have not serviced it in HardFault. It is not a cause but the result of some flaw.

As for SCB registers - these are to ease debugging. Heavy or not heavy interference, what do you expect the core to do when you request it to execute an op-code that is not a valid ARMv7M instruction?? Just read out an LR, read the stack and find out where that came from.
Similar with IMPRECISERR.
 

Due to various reasons I can't have a debugger connected to the device while it's running.

Oopsie. A debugger does all that stack analysis automagically. It seems you have to write down your own BSOD service and some logging - painful..
Or - you can alternatively connect a debugger to a running target that went haywire.