Dealing with low power mode (stop2) and memory map octospi on STM32U5

[pascal38]

Hi,

We've successfully implemented the use of external RAM connected via the OCTOSPI1 interface on the B-U585I-IOT02A board, using the example code provided in the CubeMX packages for read/write operations. Everything works as expected under normal conditions.

However, things get complicated when we introduce Stop2 mode. Upon exiting Stop2, the system enters the HardFault handler, suggesting a fault likely triggered during or immediately after wake-up.

According to the datasheet, the OCTOSPI interface is frozen during low-power modes, and its register values are preserved. Based on this, I assumed that reconfiguring the clocks after exiting Stop2 would be sufficient—but apparently, it's not.

Has anyone successfully implemented external RAM access with Stop2 mode? Are there additional steps or configurations required before entering or after exiting Stop2 ?

Note : the issue happens only out of the debug mode (when the debug probe is not used) !

Thanks in advance for any insights!

[KDJEM.1]

Hello @pascal38 and welcome to the community;

Which STM32U585 revision are you using (X, W, U)?

I recommend you to look at the errata sheet and check the erratum related to stop2 mode.

May How to debug a HardFault on an Arm® Cortex®-M STM32 article can help you to debug faults.

I hope this help you.

Thank you.

Kaouthar

[pascal38]

Hi Kaouthar,

Thanks for the information and the errata sheet.

Unfortunately, I’m not sure about the silicon revision—my evaluation board just stopped working (it is my fault, I was measuring some signal with a scope and I do make a short somewhere...).

We’ve developed our own board based on the STM32U5A5 device, using the same architecture as the B-U585I-IOT02A. Sadly, we’re encountering the same issue: a hard fault handler is triggered when accessing external RAM after exiting Stop2 mode. I saw an interresting thing in the STM32U5A5 errata sheet which may linked to my issue. But my workaround does not work.

Are you sure there is nothing to do after exiting from low power (except reconfiguring clocks) on octospi side or ram configuration ?

Thanks,

pascal

[KDJEM.1]

Hello  @pascal38 ,

If you use STM32U5A5 device, please make sure after exiting Stop 2 or Stop 3 mode, execute a dummy read in the external memory before reading it. 

Do you have the same problem when DQS is disabled ?

Thank you.

Kaouthar

[pascal38]

Thanks Kaouthar,

yes I have read this errata sheet and I have tried dummy read. Perhaps I did not do that correctly but it did not solve my issue. I do something like this after exiting low power and clocks reconfiguration :

volatile uint8_t *temp = (uint8_t *) OCTOSPI1_BASE;
uint8_t dummy = *temp;
...

I work with DQS enable (OctoSPI settings directly comes from OSPI_PSRAM_MemoryMapped cubeMx example project).

Thanks,

Pascal

[KDJEM.1 · Accepted solution]

Hello @pascal38;

Could you please try to switch the feedback clock from the DQS to the Free running clock just to deassert the reset  and then switch back to the DQS for the read operation. 

// Free running clock mode (without using DQS)
OCTOSPI1->CR |= OCTOSPI_CR_ABORT_Msk; // Abort to be able to update some Octospi registers
 while (OCTOSPI1->SR & OCTOSPI_SR_BUSY_Msk) {}; // Wait BUSY = 0
OCTOSPI1->CCR &= ~(OCTOSPI_CCR_DQSE); // Disable DQS
OCTOSPI1->DCR1 |= OCTOSPI_DCR1_FRCK_Msk; // Enable Free Running Clock
// Loop to be sure to get several clock cycles on OCTOSPI feedback clock on Delay Line 
for (uint16_t i = 0; i < 10; i++) {
      __asm("NOP");
    };
// Normal mode back (with DQS)
OCTOSPI1->CR |= OCTOSPI_CR_ABORT_Msk; // Abort to be able to update some Octospi registers
while (OCTOSPI1->SR & OCTOSPI_SR_BUSY_Msk) {}; // Wait BUSY = 0
OCTOSPI1->CCR |= OCTOSPI_CCR_DQSE; // Enable back DQS
OCTOSPI1->DCR1 &= ~(OCTOSPI_DCR1_FRCK_Msk); // Disable Free Running Clock

Please let me know if the issue is solved or not?

Thank you.

Kaouthar

[pascal38]

Hello Kaouthar !

Wonderful !

I add your code after exiting from low power and after clocks reconfiguration.

And this workaround seems to work !

I do not understand why I had to force the deassert of the reset, but it has solved my issue !

Thank you very much for your help and your solution !!!!

Pascal