Thanks for what you did, I can help test it tomorrow (it's already 9pm here)

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:   -16 -0.002% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

By the way, the flash clock frequency that XIAO RP2350 can work properly is about 50Mhz, and it cannot work properly at 75Mhz

I set it to 60 because 50 is too low and may cause PR not to be accepted (

According to the conversion of the original code, the divisor is still 3 at 60, so the clock frequency is still 50Mhz (

Thanks for what you did

Any time! I'm a little embarrassed that we didn't catch this oversight sooner!

By the way, the flash clock frequency that XIAO RP2350 can work properly is about 50Mhz, and it cannot work properly at 75Mhz

Is that a minimum of 50MHz and a maximum of 60MHz?

At 150MHz clock sys on the RP2350, and a PICO_FLASH_SPI_CLKDIV of 4 you would have been running at 37.5MHz, with a maximum overclock ceiling of somewhere around 240MHz which makes sense. That's roughly about as far as I can push the Pico before needing an overvolt.

If we configure:

#define MICROPY_HW_FLASH_MAX_FREQ               (50000000)

Then it should always run at 50MHz... in theory! A small performance bump with no risk of user overclock taking it out of range.

For tomorrow: If you revert to an older MicroPython and try to hit 250MHz machine.freq(250_000_000) (flash will be at 62.5MHz I think) then does it still run?

Apologies for the oversight that not everyone would be using a 133MHz capable flash.

Thanks @Gadgetoid for fixing it up - that change looks sensible to me. Though it's a shame that means most builds will cap the flash frequency at 75MHz (PR2350) or 62.5MHz (RP2040).

We should set the MICROPY_HW_FLASH_MAX_FREQ on Pimoroni Micropython builds to keep the extra speed!

We should set the MICROPY_HW_FLASH_MAX_FREQ on Pimoroni Micropython builds to keep the extra speed!

Agreed! And across the various boards that don't have upstream configs 🤦

I wonder if this change broke any cheap Pico clones...

Thanks for what you did, I can help test it tomorrow (it's already 9pm here)

Update: The current commit can make XIAO RP2350 work properly

Thanks for what you did

Any time! I'm a little embarrassed that we didn't catch this oversight sooner!

By the way, the flash clock frequency that XIAO RP2350 can work properly is about 50Mhz, and it cannot work properly at 75Mhz

Is that a minimum of 50MHz and a maximum of 60MHz?

At 150MHz clock sys on the RP2350, and a PICO_FLASH_SPI_CLKDIV of 4 you would have been running at 37.5MHz, with a maximum overclock ceiling of somewhere around 240MHz which makes sense. That's roughly about as far as I can push the Pico before needing an overvolt.

If we configure:

#define MICROPY_HW_FLASH_MAX_FREQ               (50000000)

Then it should always run at 50MHz... in theory! A small performance bump with no risk of user overclock taking it out of range.

For tomorrow: If you revert to an older MicroPython and try to hit 250MHz machine.freq(250_000_000) (flash will be at 62.5MHz I think) then does it still run?

PICO_FLASH_SPI_CLKDIV

To be honest, I'm not sure about the specific clock range that might work.

Previously, the clock frequency was set according to PICO_FLASH_SPI_CLKDIV, so only cases 2 and 4 were tested, that is, 75 Mhz (not working) and 37.5 Mhz (working properly).

Another case is that when 2350 first supported Micropython, the clock frequency was always 50 Mhz (cannot be changed according to PICO_FLASH_SPI_CLKDIV), but this frequency can work normally.

The last question: the old firmware doesn't work at all, so there is no way to set machine.freq(250_000_000) through the serial port.

Update: I may have misunderstood your meaning. I used Micropython compiled from this commit
416c6cf and the following problem occurred：

PROBLEM IN THONNY'S BACK-END: Exception while handling 'execute_source' (serial.serialutil.SerialTimeoutException: Write timeout).
See Thonny's backend.log for more info.
You may need to press "Stop/Restart" or hard-reset your MicroPython device and try again.

Update：

>>> machine.freq(175000000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot change frequency

Do you know the part number for your flash chip? I can look it up and see what the datasheet says (if it says anything at all!).

I'll see if I can get my hands on a XIAO RP2350 for future reference, too.

machine.freq(170_000_000)

Should work, for some reason (can't find a divider?) 175000000 doesn't work for me either.

If 250000000 causes a crash/hardlock then presumably that's putting the flash out of acceptable range (62.25MHz). 50 MHz (machine.freq(200_000_000)) seems like a reasonable bet.

I should probably rig up a flash stress test script because just changing the clock and hoping it breaks instantly is not very scientific 😆

This is our flash datasheet: 310091605_Puya_P25Q16SH-UXH_IR_Datasheet.pdf

Thanks, I’ve ordered an RP2040 and RP2350 Xaio board (same flash chip on both?) and will see how far I can push them.

Thanks, I’ve ordered an RP2040 and RP2350 Xaio board (same flash chip on both?) and will see how far I can push them.

Yes, it is the same flash

So from the datasheet it looks like the chip should support 133MHz, but there's a min read to read time of 20ns. I suspect if you add 3 << QMI_M0_TIMING_MIN_DESELECT_LSB to the timing config and set the max freq to 100MHz it should work OK.

Unfortunately I don't see any similar config on the RP2040.

Maybe it would make sense to add more parameters to control all this timing? And if we did the same on the PSRAM side it could be used to remove the assumption that the chip used was an APSxx04.

Maybe it would make sense to add more parameters to control all this timing?

Definitely a question for the MicroPython maintainers. For PSRAM I don't think we'll have a choice (we could have chip-specific config includes to handle this) but for flash it might be a struggle to eke out performance at the cost of configuration busywork 😆 that said, config includes for flash chips could work there too.

This feels more like a Pico SDK problem 😆

set the max freq to 100MHz it should work OK

Can confirm that 100MHz works for me with that change. If we can dial in the timings then we can potentially add:

• flash_generic.h
• flash_P25QXXSH ?
• flash_whatever-it-is-we-use

And so on, assuming performing tuning flash is something MicroPython on the whole is prepared to care about!

That's something for a future PR, though, since this one needs to be minimal enough to serve as a hotfix for the broken XIAO firmware. (Assuming the flash timing change isn't just reverted... I think it can be?)

I find this to be hard to maintain, and may confuse ppl when they were trying to port boards to micropython. I would suggest to take this approach. As PICO_FLASH_SPI_CLKDIV will always be defined no matter what and you always get the fastest possible flash speed.
@Gadgetoid @Lesords
You gotta decide who to change their PR.

As PICO_FLASH_SPI_CLKDIV will always be defined

This PR already relies on this, and gives setting a specific target max frequency as an optional config value.

Nonetheless PICO_FLASH_SPI_CLKDIV is wrong more often than it’s right, since it is chosen depending on the “default” RP2 clock speed (presumably only really for lazy second stage bootloader config) and there are currently at least three official values for that.

Possibly I shouldn't have confused things on this PR by talking about the wider range of flash timing settings available on RP2350 - we can raise another issue/PR for taking advantage of that.

For now, the important thing is to fix the regression on that XIAO RP2350 board. Basing the frequency on the existing PICO_FLASH_SPI_CLKDIV but providing the opportunity to override to a more exact value in the board config as this PR does seems like the best approach to me.

This PR already relies on this, and gives setting a specific target max frequency as an optional config value.

Yes, I get that part.

Nonetheless PICO_FLASH_SPI_CLKDIV is wrong more often than it’s right, since it is chosen depending on the “default” RP2 clock speed (presumably only really for lazy second stage bootloader config) and there are currently at least three official values for that.

No, well, not if the one who is porting a board is doing the right job. As I mentioned in that post, the vendor only have to get this part in mpconfigboard.cmake correct:

set(PICO_BOARD "seeed_xiao_rp2350")

In addition to that, your approach will actually limit the boards flash speed to a fixed value and leave no room for scaling. Since PICO_FLASH_SPI_CLKDIV is more than 2 for the most boards, let's assume it's value is 2 and do some math (that is, if I actually can do math....... which is not always the case.......):
The default pico sysclk:

SYS_CLK_MHZ = 125
PICO_FLASH_SPI_CLKDIV = 2
# hence
MICROPY_HW_FLASH_MAX_FREQ = 62.5 MHz

Which means, if the clock is later increased to 250MHz, we have

clk_sys = 250 MHz
MICROPY_HW_FLASH_MAX_FREQ = 62.5 MHz
# hence 
divider = 4.984f = 4

This limits the flash clock to 62.5 MHz

If you took my approach:

SYS_CLK_MHZ = 125
PICO_FLASH_SPI_CLKDIV = 2
# hence, in MHz
divisor = (125 + 133 - 1) / 133 + 2 - 2 = 1.93f = 1

The flash speed is 125 MHz, if the clock is later increased to 250MHz, we have

SYS_CLK_MHZ = 250
PICO_FLASH_SPI_CLKDIV = 2
# hence, in MHz
divisor = (250+ 133 - 1) / 133 + 2 - 2 = 2.87f = 2

Flash clock is 125 MHz.

I actually dig a bit further and got almost all max flash speed for all pico-sdk supported venders. They pretty much always can do 120 MHz. Means, my methode will even work at roughly clk_sys = (120 / (133 - 120)) * 133= 1.22 GHz. Which is a clock, let's be honest here, no rp2040 nor rp2350 is going to achieve under normal usage.

And lemme mention the most significant benefit again (your approach does this part already, but I just want to point it out again, that mine wouldn't change this nature):

Vendors only has to set mpconfigboard.cmake correctly and expect their port to work. Which should be obvious for them at the first place, since they definitively have worked with the raspberry pi foundation in order to get their boards included to the pico-sdk.

No, well, not if the one who is porting a board is doing the right job

It doesn't matter what they're doing, PICO_FLASH_SPI_CLKDIV was only intended to provide a reasonable flash clock for Pico SDK's boot_stage2 and does not get used by default in RP2350 builds.

This is cause for surprise enough that Raspberry Pi are talking about fixes for it - raspberrypi/pico-sdk#1903

Asking the original board vendor for the number they were attempting to hit when they picked "2" (or "3" or "4") (assuming they didn't just copy and paste the pico.h and/or guess) is not an unreasonable burden.

(Notably PICO_FLASH_SPI_CLKDIV only used in MicroPython's RP2350 builds because @MichaelBell mentioned it: #15619 (comment))

In addition to that, your approach will actually limit the boards flash speed to a fixed value and leave no room for scaling

This is intentional. PICO_FLASH_SPI_CLKDIV is configured by the vendor to indicate a divisor against the default Pico clock (or some other unknown arbitrary clock they had in mind at the time), thus calculating a fixed maximum frequency using CLOCK_HZ / PICO_FLASH_SPI_CLKDIV is the safest and most reasonable interpretation of their intent.

We are explicitly avoiding scaling because PICO_FLASH_SPI_CLKDIV, ie: Pico SDK itself, is fundamentally broken and doesn't make any reliable guarantees about flash config, maximum supported timings or otherwise.

Since PICO_FLASH_SPI_CLKDIV is more than 2 for the most boards

Where are you getting this information? There are 112 boards with PICO_FLASH_SPI_CLKDIV explicitly configured (and one - Metrotech Xerxes RP2040 - with some indirection) and 101 of these are configured with a div of 2.

I actually dig a bit further and got almost all max flash speed for all pico-sdk supported venders.

This could be useful information, got a spreadsheet or otherwise?

I can grep for PICO_BOOT_STAGE2_CHOOSE_ and make some assumptions based on that, but I've very little confidence that these values are reliable. The subject of this very PR is configured as PICO_BOOT_STAGE2_CHOOSE_W25Q080 for example.

As a vendor, you have entirely too much faith in vendors 😆

It doesn't matter what they're doing, PICO_FLASH_SPI_CLKDIV was only intended to provide a reasonable flash clock for Pico SDK's boot_stage2 and does not get used by default in RP2350 builds.

Ugh... not entirely sure about this part... I think this actually will be used as soon as you compile anything using the pico-sdk. But I use it as a indicator anyway. My thought is pretty straight forward. If a vendor set PICO_FLASH_SPI_CLKDIV to a value greater than 2, then the flash is on a slower side, so we have to lower the flash frequecy by increasion the divisor.

Asking the original board vendor for the number they were attempting to hit when they picked "2" (or "3" or "4") (assuming they didn't just copy and paste the pico.h and/or guess) is not an unreasonable burden.

Probably the boards were having some issues at higher cpu clocks so they had to increase the divider by a bit. I.e. vendor probably tested for 250MHz and saw they spi-flash failed (max 120 MHz) with PICO_FLASH_SPI_CLKDIV=2, hence they increased the divider to 3, so when others are overclocking the pico (which is not uncommon) they do not have to manually change the divider.

(Notably PICO_FLASH_SPI_CLKDIV only used in MicroPython's RP2350 builds because @MichaelBell mentioned it: #15619 (comment))

Ugh.... to my understanding, again, as soon as you compile the firmware using pico-sdk, PICO_FLASH_SPI_CLKDIV will be defined anyway, no matter what. That's actually why you have to set PICO_FLASH_SPI_CLKDIV=4 or so for overclocking with micropython.

This is intentional. PICO_FLASH_SPI_CLKDIV is configured by the vendor to indicate a divisor against the default Pico clock (or some other unknown arbitrary clock they had in mind at the time), thus calculating a fixed maximum frequency using CLOCK_HZ / PICO_FLASH_SPI_CLKDIV is the safest and most reasonable interpretation of their intent.

Then we could have just removed the commit that brought the dynamic flash clocking feature, set the flash to a fixed frequency, but a little pessimistic i think.

We are explicitly avoiding scaling because PICO_FLASH_SPI_CLKDIV, ie: Pico SDK itself, is fundamentally broken and doesn't make any reliable guarantees about flash config, maximum supported timings or otherwise.

We are using a fixed version of pico-sdk, so won't be a huge problem, but you are right.

Where are you getting this information? There are 112 boards with PICO_FLASH_SPI_CLKDIV explicitly configured (and one - Metrotech Xerxes RP2040 - with some indirection) and 101 of these are configured with a div of 2.

My bad, should be "more or equal than 2". And I went through the .h files here. It's exactly what you have described.

This could be useful information, got a spreadsheet or otherwise?

I.e. P25Q32SH-UXH-IR which is used by Seeed Studio and Waveshare for some of their boards. Basically I just checked boards with a default divider higher than 2, checked they schematics, see the flash model, searched these.

As a vendor, you have entirely too much faith in vendors 😆

I trust you! And others!

On RP2040 it’s always used, as it’s used to configure the flash during boot stage2.

On RP2350 you have to explicitly ask for Pico SDK to embed the XIP setup. Otherwise it’s just a dangling define that you could use, but it’s a poor substitute for configuring the flash - including all the other timing settings - properly.

And yes the reasonable alternative to this PR is just to revert the breaking change. We have reasons to not want to do that but they’re definitely a bit niche.

Probably wouldn’t hurt to find out what Raspberry Pi have planned for flash config because it’s currently - at the risk of causing a diplomatic incident - a bit of a half baked mess. 🤣

Probably wouldn’t hurt to find out what Raspberry Pi have planned for flash config because it’s currently - at the risk of causing a diplomatic incident - a bit of a half baked mess. 🤣

I wouldn't go so far to say that... but, yes, I agree that the situation is not great with the way flash speed is configured in pico-sdk. I guess it's a case of designing something simple to fit a need (configurable flash speed on RP2040 only) and then that design doesn't scale well in the future (RP2350, max frequency being updated beyond 125MHz).

I think the original intent of PICO_FLASH_SPI_CLKDIV was a simple way to specify the maximum SPI flash frequency, within the constraints of the RP2040's hardware. But it doesn't generalise:

• it's based on a fixed clock frequency of 125MHz
• it's based on an integral divider
• even worse, the multiplier must be even

We don't have much room to move here. We must assume that a vendor has chosen PICO_FLASH_SPI_CLKDIV so that SYS_CLK_HZ / PICO_FLASH_SPI_CLKDIV is the maximum frequency of the SPI flash. I know that's most likely wrong, or at least far from exact (as @nspsck argues above) but we don't really have any choice. Unless we want to go through all boards and check their schematics/BoM for the maximum SPI flash frequency -- and further have a guarantee that all boards produced actually match that BoM -- we have to go with this suboptimal max frequency calculation.

Really pico-sdk need to solve this issue and require boards to specify at least the flash frequency, if not other timing parameters. But until that happens I think the fix in this PR is the right way forward. It allows boards to get better performance if they tune the value of MICROPY_HW_FLASH_MAX_FREQ.

Really pico-sdk need to solve this issue and require boards to specify at least the flash frequency, if not other timing parameters.

I had planned to make a case for this once I understood the problem and its implications within MicroPython. It's a chicken and egg problem, and having a good case - like this - to point at is as useful starting point to advocate for change.

Rebased and merged in b725c26

Unfortunately this broke SIL_RP2040_SHIM:

$ make BOARD=SIL_RP2040_SHIM
...
[ 48%] Building C object CMakeFiles/firmware.dir/rp2_flash.c.o
micropython/ports/rp2/rp2_flash.c: In function 'rp2_flash_set_timing_internal':
micropython/ports/rp2/rp2_flash.c:57:49: error: 'PICO_FLASH_SPI_CLKDIV' undeclared (first use in this function)
   57 | #define MICROPY_HW_FLASH_MAX_FREQ (SYS_CLK_HZ / PICO_FLASH_SPI_CLKDIV)
      |                                                 ^~~~~~~~~~~~~~~~~~~~~
micropython/ports/rp2/rp2_flash.c:116:31: note: in expansion of macro 'MICROPY_HW_FLASH_MAX_FREQ'
  116 |     int divisor = (clock_hz + MICROPY_HW_FLASH_MAX_FREQ - 1) / MICROPY_HW_FLASH_MAX_FREQ;
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~
micropython/ports/rp2/rp2_flash.c:57:49: note: each undeclared identifier is reported only once for each function it appears in
   57 | #define MICROPY_HW_FLASH_MAX_FREQ (SYS_CLK_HZ / PICO_FLASH_SPI_CLKDIV)
      |                                                 ^~~~~~~~~~~~~~~~~~~~~
micropython/ports/rp2/rp2_flash.c:116:31: note: in expansion of macro 'MICROPY_HW_FLASH_MAX_FREQ'
  116 |     int divisor = (clock_hz + MICROPY_HW_FLASH_MAX_FREQ - 1) / MICROPY_HW_FLASH_MAX_FREQ;
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~

This boards does set(PICO_BOARD none), which is kinda strange, but I guess we need to support that by providing a default for PICO_FLASH_SPI_CLKDIV.

@Gadgetoid are you able to make a PR to fix that? If not then I can.

🤦 testing tunnel vision strikes again.

Might not get a chance until later this week, but will look into that board either way!

Edit: I would have thought Pico SDK would set a default PICO_FLASH_SPI_CLKDIV. However this doesn't happen outside of boot2_XXXX.s It doesn't make a lot of sense to do this again so perhaps the more correct approach would be to default MICROPY_HW_FLASH_MAX_FREQ to SYS_CLK_HZ / 4

none.h (TIL that's a valid board) would default to PICO_BOOT_STAGE2_CHOOSE_GENERIC_03H which has a default PICO_FLASH_SPI_CLKDIV of 4 on both RP2040 and RP2350.

I know this is kinda potato potäto but it feels slightly more correct.

Opened as #17510