alexcekay opened a new pull request, #21348: URL: https://github.com/apache/nuttx/pull/21348
## Summary `set_device_config()` configured the DLL before writing the requested RX sample clock source to MCR0. `configure_dll()` derives the DLL setting from RXCLKSRC in MCR0, so it used the previous source: after init that is the DQS pad loopback, which yields the fixed default delay with the DLL disabled. A device sampling with the flash-provided DQS strobe (external input from DQS pad, no SCK2) at 100 MHz or more therefore ran without the DLL until `set_device_config()` was called a second time. The DLL lock wait also never ran: `config_value` was reused for MCR0 before testing it against `FLEXSPI_DLLCR_DLLEN_MASK`. Fixed by writing RXCLKSRC before configuring the DLL and keeping the DLLCR value in its own variable for the lock check. This matches the NXP SDK, where `FLEXSPI_Init()` already sets RXCLKSRC before `FLEXSPI_SetFlashConfig()` calculates the DLL, and the lock check tests the DLLCR value. The imxrt and imx9 FlexSPI drivers share this code, so both are fixed. A second commit fixes the existing code style issues reported by checkpatch.sh in both files. ## Impact - Devices using `FLEXSPI_READ_SAMPLE_CLK_EXTERNAL_INPUT_FROM_DQS_PAD` without SCK2 now get the DLL configured from the first `set_device_config()` call: with the DLL enabled at >= 100 MHz, or the override delay derived from `data_valid_time` below 100 MHz. - When the DLL is enabled, the driver now waits for the DLL to lock, as originally intended. - All in-tree users (`imx9_flexspi_nor.c`, imxrt1064-evk NOR, imxrt1170-evk NOR and FRAM) use the internal loopback sample clock. They end up with the same DLLCR (`0x100`) and MCR0 values as before, and the lock wait is not entered for them. ## Testing **Runtime, i.MX95 (Cortex-M7):** - Tested in the context of PX4 on an i.MX95 board with a Macronix octal flash (OPI DTR), port A1, `rx_sample_clock = FLEXSPI_READ_SAMPLE_CLK_EXTERNAL_INPUT_FROM_DQS_PAD`, no SCK2. - The M7 core uses a port of the imx9 FlexSPI driver to `arch/arm/src/imx9`. That port is not upstream yet (will be a follow-up PR) and contains the same `set_device_config()` code as `arch/arm64/src/imx9/imx9_flexspi.c`, with this fix applied. - Before the fix the board had to call `FLEXSPI_SET_DEVICE_CONFIG` twice and poll `STS2` itself to get the DLL enabled and locked. With the fix a single call is enough. - After a single `FLEXSPI_SET_DEVICE_CONFIG` call the board logs the root clock, `MCR0.RXCLKSRC` and `STS2`. ASLVLOCK and AREFLOCK (bits 0 and 1) are set at both tested clocks. Boot at 400 MHz root clock (200 MHz SCLK, DDR), MCUboot followed by PX4 running from the flash: ``` flexspi_nor: root 400000000 Hz, RXCLKSRC 3, STS2 0x00000827, id 0xc2 *** Booting MCUboot build fefc398cc13ebbc527e297fe9df78cd98a359d75 *** Booting from /dev/ota0... HW arch: NXP_IMX95 PX4 git-hash: c5095fb91549674060ef36f2965ef1fdd67a755e PX4 version: 1.18.0 80 (17956992) PX4 git-branch: pr-board-imx95 OS: NuttX OS version: Release 12.12.0 (202113279) OS git-hash: b460f7d2da6eedc2f3f6557e11388a9fe5c52cd4 Build datetime: Oct 27 2026 17:42:35 Build uri: localhost Build variant: default Toolchain: GNU GCC, 13.2.1 20231009 PX4GUID: 000affff0000000000000000000000000000 MCU: IMX95, rev. 0 ``` Same board with the root clock lowered to 100 MHz: ``` flexspi_nor: root 100000000 Hz, RXCLKSRC 3, STS2 0x00002aaf, id 0xc2 *** Booting MCUboot build fefc398cc13ebbc527e297fe9df78cd98a359d75 *** Booting from /dev/ota0... ``` **Build, imxrt:** - Built `imxrt1064-evk:nsh` with `CONFIG_IMXRT_FLEXSPI1=y` and `CONFIG_MTD=y` (arm-none-eabi-gcc 13). `imxrt_flexspi.c` and the board's `imxrt_flexspi_nor.c` compile without warnings. - Not runtime-tested on imxrt hardware (it uses the same FlexSPI driver code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
