Haven't really tried, but I've seen MicroPython struggling to save files in it's LittleFS storage when I leave the clock high (need to test more). But, if I put the clock back after running at max, everything looks OK. I suspect it's more an SDK / ROM issue setting QMI Direct Mode (probably) used for flashing:Have you when overclocking been able to write to flash at any of the higher speeds?
The maximum I can achieve is 396MHz on an application that includes LittleFS writing to the flash.
Direct mode has its own clock divisor and RX sampling delay, configured by DIRECT_CSR.CLKDIV and DIRECT_CSR.RXDELAY. These are separate from the per-window settings configured in M0_TIMING/M1_TIMING, because serial commands used for control purposes may have different frequency limits than data accesses used for execute-in-place.
I suppose that by SPI you mean QSPI/QMI interface. What I've seen in ROM it uses divider 3 by default (or 6 when booting in debug mode) with all QMI channels. That would explain why you cannot pass 396MHz / 3 = 132 MHz. Maybe those routines doesn't expect to have such higher frequencies and uses the default divider.Anything more than this and the application runs fine but as soon as anything tries to write to the flash it locks up. I've played with the spi clock divider (by default divide by 4) and can't get above the 396MHz even though the SPI is running well below 133MHz. Any ideas or just confirmation that it is possible to go higher while supporting flash write would be appreciated
So far, I would suggest to lower the clock when writing to Flash (can be disruptive for other things)
I will try to tune the Direct Mode registers to see if it works.
Another way would be to write/use your own Flash routine running in RAM.
Or summon The God of SDK (in the person of kilograham, I guess)
Statistics: Posted by gmx — Tue Nov 12, 2024 6:55 pm