RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after reset We build a communication stick on the RW612 (u-blox IRIS-W10 module, CHIP_INFO 0x7002). Code runs XIP from an external 16 MB QSPI NOR on FlexSPI port A1, and a 2 MB QSPI PSRAM (APS1604M-3SQR, no DQS) sits on port B1 of the same controller. Firmware: MCUXpresso SDK 25.06.00 + FreeRTOS, and Zephyr 4.5.0-rc1. We see three issues and would like the root cause and the recommended settings. The full report with measurements, what we ruled out, register addresses and code excerpts is attached. 1) Data mixing between the FlexSPI ports with the CACHE64_CTRL0 write buffer enabled With the PSRAM accessed through the code-bus window and code running XIP from port A, a PSRAM access sometimes returns a word of flash and an instruction fetch sometimes returns a wrong word (BusFault/UsageFault in our heap code and in the ENET interrupt). A/B on images with identical code addresses: buffer on, 9 faults in about 115 min; buffer off, 0 faults in about 195 min (p about 1e-4). The SDK SystemInit() enables this buffer under XIP. - Is there an erratum or restriction for CACHE64_CTRL0 CCR.ENWRBUF with PSRAM on port B and XIP on port A? Is the SDK default safe? - Is the system-bus window (0x28000000/0x38000000 with CACHE64_CTRL1, as suggested in Zephyr GitHub issue 99943) mandatory for PSRAM next to XIP? Is the CTRL1 write buffer safe? Which AHB RX buffer / prefetch setup do you recommend (buffer 7)? - What is the mechanism of the mixing in both directions? 2) The PMU gates the CM33 clock (gate_cpu_clk), the core resumes only when a debugger attaches The board freezes with no reset and no fault record, with no WFI in the image (FreeRTOS); the moment a debugger connects (even a bare Cortex-M33 attach) it runs again. SysTick/ENET counters read before a halt and DWT_PCSR samples show the core not advancing. Only an armed WWDT0 on LPOSC with reset enabled has prevented it (0 failures in 70 min vs 6-7 per 20 min without). On Zephyr the same class shows as a core that stays in WFI with an enabled OS timer interrupt pending; an idle loop without WFI avoids it. - When does the PMU gate the CPU clock without WFI and with SCR = 0? Why does a debug connection release it, and why does an armed WWDT reset prevent it? What does SYSCTL2 SOURCE_CLK_GATE CPU_CLK_EN actually control? - What wake-up / PMU configuration does plain WFI need on RW612? Is a busy idle without WFI an acceptable long-term strategy? 3) MCI_IO_MUX FSEL bit 3 (QUAD_SPI_PSRAM, 0x40004020) clear after a deeper reset After a WWDT reset following a hang, the QUAD_SPI_PSRAM function select bit was clear, the PSRAM pads floated, and every read returned 0x1797523E until our code applied the pin group again. Zephyr does not apply this pin group itself. - Which reset types reset MCI_IO_MUX FSEL and the pad pulls? Does the ROM touch FSEL? Is Zephyr support for PSRAM next to XIP (pins, LUT separation, cache policy) planned? Open item: ENET receive errors on Zephyr (ENET_GetRxFrameSize status 4001, BABR / CRC errors) with KSZ8081 over RMII at 100 Mbit/s full duplex - is this a known issue? Our current workarounds (CTRL0 write buffer off with PSRAM, system-bus window, WWDT0 on LPOSC with reset, idle without WFI, re-applying the PSRAM pin group at every boot) are in the attached report. Thank you for any guidance. Product: WiFi RW6XX Re: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r Dear @dimush ,
Based on our overall analysis, we should first resolve the data corruption/mixing issue between Flash and PSRAM.
We need to ensure that the following configuration is correct:
FlexSPI Port A -> QSPI NOR Flash -> code-bus/cache0 -> XIP FlexSPI Port B -> PSRAM -> system-bus/cache1 -> heap/data
We also recommend: CACHE64_CTRL0.ENWRBUF = 0 CACHE64_CTRL1.ENWRBUF = 0 // During troubleshooting PSRAM prefetch = disabled // During troubleshooting
[Note]
Flash and PSRAM should use their respective correct AHB mapping paths. The RW612 Flash cache and PSRAM cache are mapped to the code bus and system bus, respectively. Only after modifying the FlexSPI LUT, reconfiguring a port, switching memory aliases, or modifying memory through an IP command is it necessary to wait until FlexSPI is idle and clear the corresponding AHB RX/TX buffers and CPU cache. The cache should not be cleared before every normal PSRAM heap access.
During troubleshooting, the PSRAM non-cacheable system-bus alias can also be used to further isolate the cache mechanism.
Thanks,
Best Regards,
Weidong
Re: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r Thank you, Weidong. Our Zephyr build already uses this layout: XIP from port A through the code bus / CACHE64_CTRL0 (ENWRBUF = 0), PSRAM on port B through the system bus 0x38000000 / CACHE64_CTRL1, no cache maintenance in the normal heap path. Since we moved to it, we have not seen the data mixing of issue 1. We will now also run with CACHE64_CTRL1.ENWRBUF = 0 and PSRAM prefetch disabled, A/B against our current image, and report the result. The remaining problem is issue 2: about once per 18-20 board-hours the whole core stops. The SysTick-driven timer and the work queue stop together within about 1 s after the last watchdog feed, and only the WWDT0 reset recovers it. This happens with idle without WFI and with the system-bus PSRAM window already in place. Could you comment on when the PMU gates the CM33 clock without WFI, and on issue 3 (MCI_IO_MUX FSEL bit 3 cleared after a WWDT reset)? Re: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r Dear @dimush ,
Thanks for your update.
Regarding Issue 2, please use the following reference flow to verify your PM2 entry and wake-up configuration. After making any necessary adjustments, please check whether the issue can still be reproduced.
First, establish a PM1 baseline:
PMU remains in PM0
SCR.SLEEPDEEP = 0
Execute WFI
In PM1, any enabled and valid interrupt source should wake the CM33.
Before entering PM2, the wake-up source must be configured at all required levels:
Enable and configure the peripheral timer or GPIO interrupt;
Enable the corresponding NVIC interrupt;
Enable the corresponding PM2 wake-up source in the PMU wake-up mask;
Ensure that the clock required by the wake-up source remains active in PM2;
Clear any stale peripheral interrupt status;
Program the next valid timer match/compare event.
A pending NVIC interrupt alone does not prove that the source is configured as a PM2 wake-up source. PM2 supports wake-up sources such as timers, GPIO, FlexSPI, USB, DMA, and Ethernet.
The documented PM2 transition is:
PM0 -> PM2:
Set PMU pwr_mode = 2'b01
Execute WFI
In PM2, the CM33 clock is gated while the CPU state is retained. The AON domain and the selected PM2 wake-up source remain active.
The following code is intended only to illustrate the sequence and is not meant to be copied directly:
configure_wakeup_source();
enable_peripheral_interrupt();
enable_nvic_interrupt();
enable_pmu_pm2_wakeup_source();
clear_peripheral_interrupt_status();
program_next_timer_event();
/* Keep CPU_CLK_EN enabled before entering PM2 */
set_pmu_power_mode(PM2);
__DSB();
__ISB();
__WFI();
__ISB();
For the production implementation, please use the power-management API provided by the corresponding MCUXpresso SDK version instead of directly programming the PMU registers. The SDK API names may vary between SDK versions.
Please also verify that SYSCTL2.SOURCE_CLK_GATE.CPU_CLK_EN remains enabled before entering PM2. This bit should not be cleared to emulate PM2; CPU clock gating should be performed by the PMU power-mode transition.
Please record the following values immediately before entering PM2:
PMU pwr_mode
SCB->SCR
SYSCTL2.SOURCE_CLK_GATE
CPU_CLK_EN
PM2 wake-up mask
NVIC enable/pending status
Timer enable/status registers
Finally, please test the FreeRTOS no-WFI configuration separately:
No WFI
SCR.SLEEPDEEP = 0
PMU pwr_mode remains PM0
CPU_CLK_EN = 1
If the CM33 still stops under these conditions, the behavior should not be considered a normal PM2 transition. It should then be investigated as an unexpected clock-gate operation or a possible RW612 PMU/clock-gating silicon issue.
Regarding Issue 3, after a WWDT reset, the RW612 restarts through the Boot ROM boot flow:
Boot ROM -> FlexSPI NOR/FCB -> Application Image
If the application image contains the PSRAM pin-mux configuration code, that code should be executed again and take effect. Therefore, please verify that the application code includes the required PSRAM pin-mux configuration.
Thanks,
Best Regards,
Weidong
Re: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r Thank you, Weidong. We ran the FreeRTOS no-WFI test you asked for on our fast reproducer board. Conditions, set explicitly after BoardInit and re-checked every second: no WFI anywhere in the image (verified by disassembly; tickless idle off), SCB->SCR = 0 (SLEEPDEEP = 0, SLEEPONEXIT = 0), PMU PWR_MODE = PM0 (PWR_MODE_STATUS = 0), SYSCTL2.SOURCE_CLK_GATE = 0x700100D2 (CPU_CLK_EN = 1), WWDT disabled. Note: ROM/bootloader left SOURCE_CLK_GATE = 0x300000C6, i.e. CPU_CLK_EN = 0, with the core running. Result: the CM33 stopped 3 times within about 7 minutes (first stop after about 6 minutes of uptime). SysTick and the OS timer gap check show that the core did not advance until our debugger attached: 12.4 s for the first stop, then whenever we attached. Each time the interrupted thread was the lwIP RX task, PC 0x20002344 (code in SRAM). Register snapshot 1 s before the stop: PWR_MODE 0, PWR_MODE_STATUS 0, WAKEUP_LEVEL 0x3, WAKEUP_MASK 0x20, WAKEUP_STATUS 0, PM2 masks 0x0/0x200/0x800000, SCR 0, ICSR 0x00400000, SOURCE_CLK_GATE 0x700100D2, NVIC ISER 0x00010400/0x00040000/0/0x00080000, ISPR3 0x120, SysTick CTRL 0x10007, CLKCTL0 PSCCTL0..2 0x02410E07/0x0E020001/0x8, CLKCTL1 PSCCTL0..2 0x08000D00/0x00010003/0x8000004D. After the attach DHCSR = 0x01100001 (running). By your criterion this is an unexpected clock-gate, not a PM2 transition. Two more observations: with WWDT0 armed on LPOSC the stop did not occur on FreeRTOS earlier (0 in 70 min). On Zephyr, a build whose idle loop reads the OS timer on every pass ran 91 board-hours without a stop (about 4 expected), and we are isolating that now. We can attach the full register dumps. What would you suggest as the next step, and is there a known erratum for this? Re: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r Dear @dimush ,
Thanks for you update.
Continuing the investigation at the lowest register and IP-command levels may lead us in the wrong direction. We should take a different approach: assume that the RW612 and the u-blox W10 module are functioning correctly, and restart the investigation from the SDK level.
You mentioned that you are using a W10 module. I have previously debugged the u-blox W10 EVK. Please confirm whether your module uses the FM25Q128A QSPI NOR Flash. We can then verify:
The FCB Flash timing configuration;
The runtime LUT configuration.
In addition, the PSRAM on the W10 is customer-added. Please provide its part number and specifications. We also need to verify its LUT configuration.
Thanks,
Regards,
weidong Re: RW612: FlexSPI port mixing (CACHE64 write buffer), PMU gates CM33 clock, PSRAM FSEL lost after r Thank you, Weidong. Here is the configuration; the full FCB, the runtime registers and the LUT words read back from a running board are in the attached RW612_FlexSPI_config_dongle_c0.txt. Flash: yes, it is the FM25Q128A - Fidelix, JEDEC ID F8 42 18, 16 MB, on port A1, XIP (our first report wrongly said "Fudan"). The FCB at 0x08000400 is the u-blox IRIS-W1 "Fidelex 8/16 MB" flash_config.c (FRDM-RW612 based): readSampleClkSrc 1 (DQS-pad loopback), CS hold/setup 3/3, sflashPadType 4, serialClkFreq 7 (133 MHz enum; FRDM-RW612 has 5 = 100 MHz), QE set via WRSR 01h with 0x0200, read sequence EBh 1-4-4 with mode byte 0x00 and 4 dummy cycles (LUT 0x0A1804EB 0x32041E00 0x00002604). The ROM cannot read this part's SFDP, so the full FCB is used. Runtime: the bootloader sets the FlexSPI root to 130 MHz; the Zephyr application keeps the controller setup under XIP, the runtime read LUT is identical to the FCB, and our PSRAM init sets the root divider to /3. With MCR0.SERCLKDIV = 1 the serial clock is about 43 MHz on both ports (measured: 43 MHz on the PSRAM SCLK). MCR0 0xFFFF1110, MCR2 0x200009F7, AHBCR 0x00200078, FLSHA1CR1 0x63. PSRAM: AP Memory APS1604M-3SQR, 16 Mbit, 2.7-3.6 V (3.3 V supply), QSPI SDR, no DQS pin (RDQS pulled down), 109 MHz max at 3.3 V, tCEM 8 us. Port B1: 2 MB, CS hold/setup 3/3, dataValidTime 1, write mask off. LUT read EBh 1-4-4 with 6 dummy cycles (0x0A1804EB 0x26043206), write 38h 1-4-4 (0x0A180438 0x00002200), reset 66h/99h. It is accessed only through the system bus at 0x39000000 with CACHE64_CTRL1; XIP uses the code bus with CACHE64_CTRL0.ENWRBUF = 0. Measured with a scope on the PSRAM in this configuration: SCK 43 MHz and CE# low pulses up to 19 us (APS1604M tCEM is 8 us). Port B sampling matches the FRDM-RW612 reference (DQS-pad loopback for both ports, RX_CLK_SRC_DIFF = 0). On the core stop: on Zephyr it also happened with your troubleshooting settings (CTRL1 write buffer off, prefetch off). Our two current builds - one with a trace hook and no idle hook, one whose idle loop reads the OS timer - ran about 50 board-hours without a stop (about 2 expected).
記事全体を表示
