Closed GeorgeCGV closed 1 month ago
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
Using XIP (memory map mode) introduced in #68597, #72339 with the (Q|O)SPI with a clock source set to PLL1 leads to an application stall/freeze.
It happens right after https://github.com/zephyrproject-rtos/zephyr/blob/67a31ef2d781231aacb44b6a99681750a01123d5/drivers/clock_control/clock_stm32_ll_h7.c#L769
The PLL1 disabling before configuration was introduced back in #57337. The disabling makes sense. However, for some reason PLL2 and PLL3 were left out.
To allow the application to boot successfully we must not disable the PLL(1|2) when it is used by (Q|O)SPI peripheral.
The issue was mentioned in https://github.com/zephyrproject-rtos/zephyr/pull/62349#issuecomment-1711483187.
To Reproduce Steps to reproduce would be to build and run an application that uses (Q}O)SPI in memory map mode when it is clocked from PLL1.
Expected behavior Ideally, the application boots in memory map mode with a reconfigured (Q|O)SPI clock.
That would require to extend existing drivers to support clock reconfiguration and to switch (Q|O)SPI clock selector to
HCLK
before that.The peripheral prescaler depends on the bus clock and can be changed only when the memory map mode is aborted. Consider that the read opcode might come from SFDP. Overall, it will require some refactoring in the driver. Apart from that, the driver code might need to be in RAM.
A quick solution would be not to disable PLL which is used as the the clock source for the (Q|O)SPI when executing the application in memory map mode.
Impact Showstopper when an application runs in memory map mode for (Q|O)SPI clocked from PLL1.