standby in stm32u375 achieved

[geoffrey.brown]

I struggled mightily trying to get the stm32u375 into standby mode in my application. stop3 worked fine, but standby got stuck in a high-power state. However, standby worked fine after hal and ch init, but not after talking to my sensors. The final thing that worked --

rccResetSPI1();
__DSB();

in my standby routine. It looks like the spiStart() routine does reset spi, but not the spiStop() routine. So things can get left in a state that the standby hardware doesn't like.

Geoffrey

[Giovanni]

Apparently there is an even deeper problem with the SPIv3 and SPIv4 drivers, I am looking into this.

Giovanni

[Giovanni]

This triggered some changes in the SPI driver, see the explanation here: https://github.com/chibios-upstream/chibios/pull/231

Could you feedback about your use case?

Giovanni

[geoffrey.brown]

I'm not completely clear what you are asking me to do.

My use case is a bit unusual. I have devices that spend much of their life in standby and wake periodically from a wakeup even (either the rtc or a wakeup pin). Typically, they collect and store some data and then go back to standby. The problem I encountered was that after the data collection stage, the device wouldn't enter standby. More specifically, the wfi worked, but the processor stayed in a high energy state. Although this is certainly a failure of the standby logic in the stm32u375, to proximate cause was that after performing a spi command and stopping the spi device, some residual state caused standby to fail. Reseting the spi device cleared the problem state.

[Giovanni]

An error in the SPI driver caused the SPI unit to be still active after spiStop(), this is likely the cause of your device not entering the stop state.

The driver has been fixed, now the device should be able to enter stop without other workarounds, I just asked to confirm.

Giovanni

[geoffrey.brown]

I ran into a problem with testing the changes -- I do my builds with the stable-21-11.x branch and there are enough structural changes to the config files that I'm reluctant to tweak my entire repo because I depend upon being able to recreate the build environment for my data loggers if there is a problem in the field. So, I tried pulling the changed file into my repo to override the stable-21-11.x version. It did achieve standby, but unfortunately eventually caused a crash -- I'm not sure whether this is due to other changes that are incompatible with the stable branch. My application, which is an IMU for tracking flight dynamics of flying animals, hammers spiStop and spiStart at a pretty high rate.

Geoffrey

[Giovanni]

You could just port the change in spi_lld_stop(), it stops the SPI unit by writing in registers instead of calling that abort function, that is the only change that matters.

Giovanni

[geoffrey.brown]

That didn't work well -- still crashes after a while. I do use stop1 when the IMU is running while waiting for an interrupt. Not sure if that's the issue, but clearing the registers definitely makes something unhappy. I've found this part has a lot of subtle issues that aren't explainable by reading the reference manual.

Geoffrey

[Giovanni]

What is the result of the crash? are you running with assertions and state checker enabled?

Giovanni

[geoffrey.brown]

ok, I spent a long time trying to debug this, but don't have a root cause. The basic model is
1) wake,
2) collect some data
3) write to external flash cache
4) program external page when full

After the cache actions, the code goes to stop1. When waking after (4), the code (every K times) writes a header block to internal flash. This write operation is what is failing with FLASH_SR_PGSERR. It does not fail if I don't clear CR1 an CFG1 spi registers.

So, there is some subtle coupling between clearing spi registers and the core system.

Not a ton to go on I know. Also, without clearing cr1 and cfg1, it's still necessary to do rccResetSPI1(); before standby. The power modes on this part are really wonky