STM32U545 hold-up time required to log an event to flash

[Daniel Glasser]

We are working on a design that includes an STM32U545 running at around 1MHz to save battery power for the overall board.  We have a requirement to write to an event log when the power is removed (this is the main operating power, not VBAT).

The software will keep the STM32U545 in Stop 2 mode between external events and LPTIM1 events to further minimize power consumption, waking only long enough to read and evaluate the changes in the environment before stopping pending the next event.

One of the events is from the power monitor circuit on the board that will change the level of a signal going into a GPIO of the STM32U5 when the power source (external or battery power, automatically selected by the power monitor) drops below the required voltage. The requirement is that the power-loss event be logged for recovery when the power is restored.  To this end, the EE designing the board is including a capacitor to provide hold-up power to allow the software to respond to the power loss event and write the log entry (less than a 128 bit page) to a known location.

I'm the software architect for this project, and I've been tasked with determining how long, from the power loss signal to the completion of the flash write, will be required. Due to board space and other considerations, this must be quite minimal - he's proposing 1ms, but I've not used the STM32U5s previously and we don't have any dev boards for me to simulate the conditions on yet, so it's hard for me to calculate from the timings in the datasheet alone.  I have been given 2 days to provide this information to include in a proposal.

Is there a resource that I can use for this?  I can work out roughly how much code is involved once the processor wakes up and starts executing the handler. I know the CubeMX tool has a power estimator, but what I need is a time estimate from interrupt to handler execution at a given clock rate and assuming the Stop 2 state as the starting point.  I also have not worked out how to configure the timing parameters to set the core clock rate to 1MHz since what I see in the Clock Configuration panel doesn't make a lot of sense to me (am I looking for SYSCLK, HCLK, etc.?).

Thanks in advance.

[Tesla DeLorean]

Is BKPSRAM (2KB) an option?

Can you find someone on FIVERR with hardware? Or some who can TeamViewer w/HW? Some one at DigiKey or your distributor? An ST sales office or rep?

Can you prototype some code, perhaps using TIM2 as an elapsed time counter, and quantify write time to a pre-erased section of FLASH?

 

[Daniel Glasser]

@Tesla DeLorean : The BKPSRAM is not an option because it requires the battery power (VBAT) to be kept up. Our device has a battery, but that battery is removable and non-rechargeable, and the requirement is that loss of all power (including the battery) is to be logged as a significant event that can be retrieved via a maintenance interface after power is restored. I can't go into the details as to why this is important.

In "normal" conditions, this platform should never be without some source of operating power; a circuit external to the STM32L5 will select between the external source and the battery; if external power is available, it uses that, otherwise the battery.  The hold-up capacitor is sufficient to smooth out the transition from external power to battery, and this powers both the operational power and VBAT. I need to work out the amount of additional capacitance is required to provide enough hold-up to do the logging before the operating power goes below 1.6V.  This is a maintenance circuit, not the primary computing resource.

The original idea was to have a low-power FPGA in place of the STM32U5, but there was no part with the required number of gates that can be sustained with a small battery (around 1.6Ah) for the required period. The STM32U545 has been selected because, when it's in STOP 2 mode w/RTC, draws uA rather than mA.

If I had, say, a NUCLEO-U545RE-Q in house, I'd do the analysis myself. All I have are a few NUCLEOs with STM32L0s, however, and I do not expect the timing to be sufficiently close to be able to give the hardware designer a reasonable number - If I ask for too much time, the capacitor gets larger, and we have a hard z-height limit with board space being at a premium.

I will check to see if our reps can help me, but being the SW engineer, not an EE, I don't have frequent interactions with them.

 

[Daniel Glasser]

Follow-up:  I made some rash assumptions, and have come up with a ballpark figure of 698us using the expected MSI clock rate of 1MHz, Stop 2 w/RTC, running from SRAM2, and roughly 500 instruction cycles, which I hope is an overestimate.

[Pavel A.]

We have a similar requirement but for other kind of systems: STM32H7 with external flash on FMC and iMX6 with eMMC. For the first, there's a super-cap that gives at least 20 ms. It is enough to write ~ 64 bytes to pre-erased sector. For the 2nd system, there's also a super cap for ~ 20 ms, but since eMMC is a "black box" I could not really warrant the needed time. All I know is that it worked 'good enough'.

Try to test on a close prototype hardware (some eval board). Write the data and toggle a GPIO when done.

[Daniel Glasser]

@Pavel A. - Thanks for the suggestion. Since we're using internal flash on the STM32U5, the interfaces themselves are a bit more closely coupled.  I wish we could put a hold-up for 20ms, or even 5ms, but the HW engineer assures me that we can't use that large of a cap for this purpose.  I have done some testing on an STM32L0 Nucleo64 board where I was able to write to flash within 1ms (according to the scope) from an interrupt, however I was not able to start in STOP 2 low power mode or get SYSCLK down to 1MHz in a project generated using STMCubeMX and then modified and built in the CubeMX IDE.  I *thought* I had set SYSCLK to 1MHz in the clock configuration tab of CubeMX, but it was running at about 16MHz.  My scope at home, unfortunately, doesn't have enough resolution to give me microsecond resolution (it's a cheap single channel STM32F4 based scope with a small TFT display), and I ran the test 4 times and got 4 different values for the interval between when the GPIO went high and then low again - Around +/- 400us (it claims to be a 100KHz scope, but 30KHz seems to be more like it).

I'm unable to bring a board into the lab at work on short notice (security reasons, usually takes about 2 weeks) or connect the Nucleo board to my desktop workstation (again, security; they've restricted the use of USB devices on the company network), so the old M0+ card I have in my personal collection had to do.

I'm told that the cap used will provide at least 1ms, maybe as much as 1.5ms, based on estimated power consumption of the STM32U5 and the sensors it monitors and the parasitic drain from connected components that are not always powered. If I can get the power consumption in STOP 2 and/or RUN down a few more uA, more time will be available, but until I have the actual devices and the tools to measure the actual current drawn by the arrangement, I really don't know.

Because this is all on paper at this moment (it's a proposal, not fully designed), I've assured my management and the EE that what I gave them is a best effort estimate that may be off by as much as 50%.

[Pavel A.]

> security reasons, usually takes about 2 weeks

Of course, all this "security" is a heavy performance hit. Being a freelance consultant, I just buy some cheap STM32 boards, plug in my own laptop - using free, public, generic software like Cube and github stuff, no any proprietary code of the customer, none of their lab gear - and can get something "working" in matter of hours.

To wire up extra parts to the ST boards, I ask friendly electronic engineers from the customer side. Again, we use only generic cheap LEDs, caps, etc., available in any tech store. Cheap USB scopes, glue tape, screws )).  If I went thru talks with the management, these hours would become weeks.