Power Optimization with STM32L4: Sleep Mode during SDMMC DMA Interrupts

[MAndr.7]

Hello, fellow forum members,

I'm acquiring data from an ADC using DMA, and writing the filled buffer in SDCard, using SDMMC, also with DMA, on an STM32L452RC.

I recently came across an interesting challenge involving power optimization while waiting for an SDMMC DMA interrupt. I wanted to inquire if it is possible to put the device into a low-power sleep mode, or any other suitable, during this waiting period. My goal is to maximize power savings by allowing the device to enter a low-power state during periods of inactivity and only wake it up when the SDMMC DMA or ADC interrupts are triggered. There's any technical limitation to achieving it?

I also have been looking at the `sd_diskio.c` generated code and in the write and read methods there's a blocking condition which is released on the DMA callback is triggered:

timeout = HAL_GetTick();
while((WriteStatus == 0) && ((HAL_GetTick() - timeout) < SD_TIMEOUT)){}

So what's the point of using DMA if it's blocking the main loop?

Best regards

[Tesla DeLorean]

>>So what's the point of using DMA if it's blocking the main loop?

That perhaps you have multiple threads, or do things in interrupt context?

You could presumably put a __WFI() in the loop so the MCU wasn't grinding unnecessarily.

Most of the examples are "Hey Look it Works" not deliverable production code perfectly tailored to your application / use-case.

[MAndr.7]

Hi @Community member​ 

Can you give me some more context? So do you think that's possible to insert a _WFI() in the write operation loop? So any interrupt that occurs in every DMA will wake up the device?

By the way, can you tell me in which state will the device fall if I insert the _WFI instruction?

Regards

[Tesla DeLorean]

Depends on how you configure it, but you want the memory and buses to continue to function.

What you don't want is the processor executing code, when all the exit criterion are driven by interrupts, ie SysTick, SDMMC or DMA, and any time one of those occurs you get to reassess the exit conditions, once. The alternative is to do the test as close to 80M times as second as you can.