Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Relafe
Level 1
Level 1
10 sign-ins First solution authored First reply posted

Hi,

I have some XMC4500/4700 boards that have to work in a slightly disturbed environnement. Sometimes, the 3.3V power-supply given to the XMC get disturbed a bit (for about 2 to 3us). I have an external power-supply supervisor that activate under 3V and cause a 240ms long reset.

I have enabled the PLL unlock trap, missing external OSC trap (I use an external 25MHz clock, not a crystal), peripheral bridges 0&1 traps. I'm running the watchdog without prealarm, and it is enabled immediately in system.c after start-up. I also activated the automatic reset in case of core lock-up. I made that the default interrupt or any NMI does trigger a SWReset.

Despite the usage of the watchdog timer (using the internal fast RC), I still have rare occurrences of lock-up. (I'm also using an external SPI flash, so I can write debugging infos in all ease at a 20ms rate, which help for debugging).

If I try to attach the debugger during a lock-up (after having programed that the WD should stop during debugging), using the device=Cortex-M4 instead of XMC4XXX..., it unlocks, continue a bit and only then halt the execution. So what I see in the registers has no value to me, as it doesn't picture the lock-up situation.

Under some lock-ups, I couldn't even connect with the debugger. I had to perform a hardware reset to be able to connect to it again. Note that when the lock-up occur, the outputs stay in the previous state, hence I can use leds to track execution.

The other way around was to record an execution trace in RAM, and do a true reset, and then connect to the XMC under reset. This allowed me to know where it was roughly before locking-up, and have other debug information. So I found this could be occuring anywhere in my code. The experience shown that the lock up was mostly occuring when the XMC has a 3state like consumption (edit, I wonder since it has not to do with the lack of external resistance on TMS and TCK on my design, perhaps it enter either of the two embeeded bootloaders, which would be easily fixable).

 

I did a small setup to reproduce, where I removed the reset supervisor and disturbed the 3.3V XMC supply a bit (I did not activate the internal powermon).

When disturbing the power-supply, I mostly get hardware faults, generally instruction/data bus faults. Then it does a software reset, and it continue to run fine.
By increasing the level of the perturbation a bit, I can easy reproduce the lock-up situations nearly at will.

I'm using the Dave IDE, but I guess it has little to do with what I'm experiencing, since I can write a small blink led example without any Dave app and still experience the same behaviour.

 

I would have expected the watchdog timer to continue running no matter what happen but it is not the case. Sometimes my board would just freeze for about 15seconds, and then just continue like nothing happened. Note that I'm using a 10ms watchdog timer period for my init, then a 1ms, so that should be quite far from that 😉 That is quite annoying for my application. I have an external watchdog that locks all outputs of the XMC through gating, so that stay safe. But at the moment I lack the possibility to reset the XMC from my external watchdog. The only way to recover is then doing a power-off/power-on, but that is quite complicated to do. Any advice about how to recover by software would be much appreciated.

 

Best regards,

Relafe

0 Likes
1 Solution
Relafe
Level 1
Level 1
10 sign-ins First solution authored First reply posted

In the reference manual there is a few information about the software that is executed before we arrive in the reset handler (SCU: Initialization and System Dependencies). But it looks like the watchdog is not activated during that process.

Relafe_0-1683734284300.png

Relafe_0-1683735362455.png

Relafe_0-1683735707593.png

Relafe_1-1683736240307.png

That may be it! No debugger access, no WDT, tristate like power consomption, and requirement to de a power-on reset. So basically if a NMI occur in the Infineon start-up code, (in my scenario, I know that instruction/data bus fault happen often) it cause a final lock-up of the death. I wonder why it was choosen not to just do a reset it this case.
If think I would be able to verify that using JTAG...

Relafe_0-1683740300000.png

But I have no debugger access and I'm using only the 2SWD pins + GND, and I have no idea how to issue a specific JTAG instruction in this case 😉

So in conclusion, beware of what happen in the first 3.5ms of boot. Don't rely on the internal watchdog timer too much, as during those 3.5ms you have none!

Relafe_0-1684754410758.png

 

Best regards,

Serafe

View solution in original post

0 Likes
3 Replies
sujatapatil
Moderator
Moderator
Moderator
10 likes received 100 sign-ins 25 solutions authored

Hello Relafe,

I am extremely sorry for delayed response due to long weekend .

you can  confirm only watchdog behavior ( Resetting CPU on timeout)  without creating hard fault exception and that   should work fine.

Since you are creating lockup state by reducing  power supply VDDc  , watchdog and CPU  becomes non functional/low power mode  as both are in same power domain.  Here system state will be retained .

What i can say from given details  is , 

1> XMC power supply is not stable and getting  lockup state (bus fault) when there is a power fluctuation .Once voltage levels are reached to expected value system continues as  nothing happened and continues from retained state . So watchdog will continue kicking without reset .

 Suggestion to use external watchdog to bring system back to operational state in this scenario .

Thanks

Sujata

If it is bus fault due to 

 

 

0 Likes

Hello Sujata, thanks for your answer.

Meanwhile I made a simple test with a XMC4500 relax kit I have, so it is fully independant of my hardware and "easily" replicable. I broke the debugger part, and power if from a 3.3V power-supply.

I then changed of strategy again, and made a small program that activated a led of the relax board in the first instructions (after having enabled vtor relocation (for NVIC) and then the GPIO module, in SystemInit) and then the watchdog and all the rest with a WD feed infinite loop. Everything is contained in startup.s/.c

I set the clock of the watchdog as also active in sleep/deep-sleep modes.
I soldered two resistances on the debug pins so I do not enter one of the embeeded bootloader by mistake.
I have enabled the PLL unlock trap, missing external OSC trap, peripheral bridges 0&1 traps. I'm running the watchdog without prealarm, and it is enabled immediately in system.c after start-up. I also activated the automatic reset in case of core lock-up. I made that the default interrupt or any NMI does trigger a SWReset.

I then approach a loop antenna (which consist of a BNC coaxial cable with the inner end soldered to the shield, making a small loop). I put a high voltage source on the BNC so it generate a small field, and when I approach the loop of the XMC, it start to do resets. Those resets doesn't bother me at all.

But with a bit of luck, after a few tries, at a very moment, the led stay off and it never recover. Of course, I had removed the small antenna in the meanwhile. Only a power-off then power-on can make it lit again (or pressing the reset button).


I never do any hibernate/sleep/deep sleep request, as my system should stay always active. My understanding is that if the power go below a threshold it should lead to a system reset. So I still don't understand how it can reach a point where the 3.3V is fully stable but the XMC stay stopped.


When reproducing the lock-up scenario with the coax loop, the led stay off. Which tend to show that the system.c was not even executed, althought the first assambly instructions are:

 

Reset_Handler:
    ldr sp,=__initial_sp
    ldr  r0, =SystemInit
    blx  r0

 


It is that which bothers me.  Having see this will force me to add the "XMC reset feature" to my already existing external watchdog, but  I have thought for a moment that the internal XMC watchdog was meant to avoid getting in this specific situation, but it looks like something bad is happening inside of the XMC before it hands of the control of execution to the user, so nothing can be done softwarly about it

Best regards,

Serafe

0 Likes
Relafe
Level 1
Level 1
10 sign-ins First solution authored First reply posted

In the reference manual there is a few information about the software that is executed before we arrive in the reset handler (SCU: Initialization and System Dependencies). But it looks like the watchdog is not activated during that process.

Relafe_0-1683734284300.png

Relafe_0-1683735362455.png

Relafe_0-1683735707593.png

Relafe_1-1683736240307.png

That may be it! No debugger access, no WDT, tristate like power consomption, and requirement to de a power-on reset. So basically if a NMI occur in the Infineon start-up code, (in my scenario, I know that instruction/data bus fault happen often) it cause a final lock-up of the death. I wonder why it was choosen not to just do a reset it this case.
If think I would be able to verify that using JTAG...

Relafe_0-1683740300000.png

But I have no debugger access and I'm using only the 2SWD pins + GND, and I have no idea how to issue a specific JTAG instruction in this case 😉

So in conclusion, beware of what happen in the first 3.5ms of boot. Don't rely on the internal watchdog timer too much, as during those 3.5ms you have none!

Relafe_0-1684754410758.png

 

Best regards,

Serafe

0 Likes