Huge current consumption when using the (Cube) EEPROM emulation example for NUCLEO

[EJacq.1]

Hi every body,

Running and exploring the en.x-cube-eeprom-v5-0-0 middleware example and the PWR_CurrentConsumption example (Cube), first on NUCLEO F429ZI and then on NUCLEOG431RB, I encountered the following issues:

1- NUCLEO F429ZI:

At a moment the board began to sink much current, between 50mA and 150mA, barely less when entered in standby mode, and then it completely burned (after a couple of hour idling, the AMMETER showing up to 800mA at the end)

NUCLEO G431RB:

I did the same with this board: entering in the same example codes, while monitoring the IDD (not the whole board as I did with the F429ZI, but only IDD). At the beginning, I saw about 6mA in run mode, falling to 0.5mA in StandBy mode. Until this moment all was OK for me since I didn't make any effort to down the current. Later I noticed that it was rather 1mA, not very stable...

But I suddenly saw the AMMETER indicating 150mA, unable (unfortunately) to say exactly when it happened. I loaded a fresh, untinkered version of the example code (EEPROM), and it seems to work again, but nothing to do: IDD is 150mA and a few mA lower when entered in standby mode. Its very surprising to experience almost the same issue on two different boards. No hardware is connected to the NUCLEO, and there is no reason for a short, unless I missed something and some internal short has occurred.

I am not very experienced in STM32, if anyone has an idea?

Thanks

[STOne-32]

Dear @EJacq.1​ ,

That level of current consumption of the MCU only is not Normal for sure, Can you try to replicate the values from Datasheets on RUN mode while having a simple while(1) main program to identify if your hardware or connection to the ammeter is fine ? It may happen there is a conflict of GPIO usage such as one pin shorted to ground while high driving.

Now, back to EEPROM Emulation, the only Extra consumption versus Normal run mode is the Power consumption of our Flash ( Erase/Write procedure) in a continous way and is about 7mA in G431 and up to 12mA in STM32F429.

Hope it helps you to debug your case.

Cheers,

[EJacq.1]

Thank you @STOne-32 for this condensed reminder of the nominal conditions and right pages of the daatshet.

Concerning the hardware, I use JP6 on the NUCLEO STM32G431RB to insert my ammeter. JP6 is there for that purpose (to measure Idd). I have checked the ammeter.The abnormal consumption does not depend on the loaded code, so I guess a simple while () will do the same, but nevertheless I can try. I'll keep you informed in case of any progression.

Have a good day

[EJacq.1]

Hello,

Here is the conclusion:

I decided to test one by one all the GPIOs in order to detect any I/O hardware misfunctionning. The first I tried, PA0, seems to be dead, because there is always 0 volts at the output, and the IDR is stuck to “1�? regardless of the ODR and/or the pushpull PUPDR configuration. When set as an input, PA0 sinks 1.5mA if 3V is applied.

So it seems to be a common, coarse failure at the I/O boundary. Effectively I remember observing bad functioning while trying to use PA0 as wake up pin, but this appart, I didn’t use that pin, even less as an output.

Thus there is probably no correlation with the failure of the 439ZI while running example code. Now we are back in the rational world, it’s better, but all the same I find this MCU not so reliable!

Regards