XMC™ Forum Discussions

Hello,

I just wanted to share some experience I had with XMC4500 and XMC4700.

I ran into an issue in the past here (don't go to look at it  ("XMC-in-lock-up-scenario..."), as it is now fully deprecated), and thought I was experimenting SSW issue (boot software). Now I have found exactly what was happening last week. I was doing some measurements that had me look at the level of an XMC input pin with a 10k pull-up resistor to 3.3V, while recording internal values in the XMC RAM, that allowed my to see that I was mistaking (ie there was no lock-up at all), and it provided me an easy method for reproducing the issue (which I kind of lacked back in the days) in a way I could do measurements in all safety (that was very slightly unsafe back in the days).

We have a dedicated board that work in a hostile environnement, and there is XMC4X00 on it, as well as an external watchdog. We protected it really well but we still have some rares issues with it in the field. We have leds on it. When the issue happen, they all lit (this is what did make me think my board was stuck in some kind of 3state init of the XMC, but it is not).

In our labo, we can reproduce the issue using a bursts generator with the setting 5.5kV 5kHz 5ms. We then apply this with a 1pF coupling on a random GPIO pin of the XMC. We did protect the pins with 1nF capacitors, so due to the coupling, the XMC pin get a very limited perturbation current.

What is happening is that during the bursts, the PORST peripheral is hardwarely disturbed. One would assume the level read on the GPIOs would be random like 1, 0, 0 ,1 ,0, 1 etc, but in fact someting else is happening.

The issue can either be transient or permanent. What it does, is that all ports that have an output driver are set as output low (I didn't check every pin, but all the ones I have accessible in P1,2,3,4,5 were). When that happen, I can read the registers of the PORTS, and everything is set as during my init. So the content of the PORST registers do not correspond to the behaviour of the pins.

Notice that the pins set as inputs, are also forced to 0V by hardware. I've tried a few things, like making sure there is no hibernation, that the hardware control was disabled, and even tried to initialise the OUT register to high for my inputs (thinking it may short it to high level then, but it didn't), but nothing helped.

The only workaround known is to reset the PORTS peripheral. As soon as it is in reset, the pin go from hardwarly forced low to 3state. If programmed again, everything works as expected.

For my project, it is quite annoying. The good thing is that the PORTS slices IN registers content are still working as expected. So I can detect when the issue occur as I then read all my inputs are low level (that can never occur in another normal situation). If that occur during 1ms consecutively, I issue a global SWReset.

By chance, my PWM are active low, but the enable gating is active high. I have an external watchdog as well. And the XMC can reset it by putting a pin low. So when the lock-up of the PORTS peripheral occur, my system is put in a safe state automatically.

One interesting thing to note, is that the PORT 14 and 15 which have no output drivers are not affected. So my ADC still give me the correct values. Even better, I had put some important digital inputs on P14-15. Those are working perfectly, and it help me figuring out if I should perform a SWReset or not.

So my system can run fine in a safestate, with just PORT 1,2,3,4,5 forced to level. All the rest of my peripherals are running correctly. The timers do the correct timings, the interrupts are working, the code does what is programmed to do etc. It is only an I/O issue. Obviously, it is not really a good surprise to have my inputs forced to 0V, especially because my inputs are something else outputs, so it shorts. In practise, the shorts seems not to be very problematic for me, since everything is internaly current limited.

I think the PORST issue should be added to the errata by the way. Even with workaround: PORTS reset.
A simple external pull-up on an XMC input can be sufficient for detection and workaround. Maybe it can even works with an internal weak pull-up.

Here is an example of measurements:
I have an external 100us clock in blue (actually not connected to the XMC and vary between +1V and +2V). The pink signal is an input of the XMC that is connected to an external 10k pull-up to the +3.3V. This pin is initialised as an input in the XMC, and the +3.3V supply is not disturbed at all.

When the bursts occur (5ms of 5kHz pulses, we can see the noise added on the blue signal), we can see the pin gets pulled low by the XMC. This can be transient, or permanent like on the last image. Note that a permanent problem can occur, even if only one pulses is given. It doesn't have to occur at the end.

PS: To determine what was the problem, I did record the inputs pin levels, and PORTS registers, as other key variables content into the RAM. By connecting the debugger to the running target with a breakpoint placed on the very first instruction in startup.c, it reset the registers and halt the XMC.  The RAM content stay untouched, which allowed me to record 1s before and 1s after the bursts application, at a 100us sampling interval, binary dump the RAM zone with gdb, and import in within a python script for browsing the data. The input levels were exactly matching what I could record with my oscilloscope.

On the following python graph, we can see the pink trace from my scope that correspond exactly to the orange trace at the end of the arrow, which is the XMC "100us sampling" of the externally pulled-up input (pink trace).

Best regards,

Relafe