Fix: solve the problem that micropython could not be used

[Lesords]

Solved the problem that micropython could not be used normally in XIAO RP2350

[lurch]

Ping @ryanplusplus and @mcauser in case they have any thoughts...

[ryanplusplus]

Doesn't the Xiao RP2350 work with Micropython? The Seeed Wiki seems to indicate that it does:
https://wiki.seeedstudio.com/getting-started-xiao-rp2350/

Can you provide some more information about why this is necessary and how you determined that it was necessary?

I checked the Xiao RP2040 and it is also using a SPI clock divisor of 2 with what I assume is the same flash chip (the schematic leaves it unlabeled). If there's a difference, I would guess it's related to the layout. However, I'm not sure why a problem would only present itself for MicroPython and not when using the C/C++ SDK directly.

[ryanplusplus]

I just noticed this warning in the Wiki:

MicroPython Firmware Issue

As of November 10, 2024, the stable MicroPython firmware version 1.24.0 available for download at MicroPython.org for RPI_PICO2 is currently incompatible with certain devices due to variations in the flash chip.

The Seeed Team is actively working to resolve this issue in collaboration with the official MicroPython maintainers. In the meantime, you can use a preview version of the MicroPython firmware as a temporary solution: RP2350 MicroPython Firmware Preview

Are you working with/for Seeed to solve this issue?

[lurch]

If there's a difference, I would guess it's related to the layout.

RP2040 also has a default clock speed of 125MHz whereas RP2350 has a default clock speed of 150MHz; so I guess if something was already operating at the margins of tolerance it'd be much more likely to not work at the higher frequencies of RP2350?

[Lesords]

I just noticed this warning in the Wiki:

MicroPython Firmware Issue
As of November 10, 2024, the stable MicroPython firmware version 1.24.0 available for download at MicroPython.org for RPI_PICO2 is currently incompatible with certain devices due to variations in the flash chip.
The Seeed Team is actively working to resolve this issue in collaboration with the official MicroPython maintainers. In the meantime, you can use a preview version of the MicroPython firmware as a temporary solution: RP2350 MicroPython Firmware Preview

Are you with/for Seeed to solve this issue?

emmm, actually, I work at Seeed

[lurch]

emmm, actually, I work at Seeed

Aha! In that case I'll approve this PR 🙂

[Lesords]

If there's a difference, I would guess it's related to the layout.

RP2040 also has a default clock speed of 125MHz whereas RP2350 has a default clock speed of 150MHz; so I guess if something was already operating at the margins of tolerance it'd be much more likely to not work at the higher frequencies of RP2350?

Yes, the current situation seems to be that the SPI clock frequency is too high to be used properly.

[ryanplusplus]

If there's a difference, I would guess it's related to the layout.

RP2040 also has a default clock speed of 125MHz whereas RP2350 has a default clock speed of 150MHz; so I guess if something was already operating at the margins of tolerance it'd be much more likely to not work at the higher frequencies of RP2350?

Yes, the current situation seems to be that the SPI clock frequency is too high to be used properly.

Do we understand why it works properly for the C/C++ SDK? Reducing the SPI clock by half will have a large performance impact.

[lurch]

Just a random guess, but perhaps C applications are "lighter weight" than MicroPython applications, and are therefore able to make better use of the XIP cache? (of course I could easily be 100% wrong)

[Lesords]

If there's a difference, I would guess it's related to the layout.

RP2040 also has a default clock speed of 125MHz whereas RP2350 has a default clock speed of 150MHz; so I guess if something was already operating at the margins of tolerance it'd be much more likely to not work at the higher frequencies of RP2350?

Yes, the current situation seems to be that the SPI clock frequency is too high to be used properly.

Do we understand why it works properly for the C/C++ SDK? Reducing the SPI clock by half will have a large performance impact.

It seems that the SPI frequency of the firmware compiled by C/C++ SDK is always 50 MHz, regardless of whether PICO_FLASH_SPI_CLKDIV is modified or not.

I'm not sure how 50 Mhz is configured.

[will-v-pi]

It seems that the SPI frequency of the firmware compiled by C/C++ SDK is always 50 MHz, regardless of whether PICO_FLASH_SPI_CLKDIV is modified or not.

I'm not sure how 50 Mhz is configured.

I think this is related to #1903 - on RP2350 the boot_stage2 isn't run by default when using the C/C++ SDK, so it just uses the flash mode setup by the bootrom. The PICO_FLASH_SPI_CLKDIV and similar defines are only used in boot_stage2, so will have no effect on RP2350 unless using a boot_stage2

[lurch]

I think this is related to #1903 - on RP2350 the boot_stage2 isn't run by default when using the C/C++ SDK, so it just uses the flash mode setup by the bootrom. The PICO_FLASH_SPI_CLKDIV and similar defines are only used in boot_stage2, so will have no effect on RP2350 unless using a boot_stage2

Oh interesting! IMHO this definitely deserves to be better documented, as currently the only mention of this in https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf is "A boot_stage2 is not needed on RP2350, but one can be included via the define PICO_EMBED_XIP_SETUP=1." which is buried in the SDK 2.0.0 release notes all the way down on page 649! (And PICO_FLASH_SPI_CLKDIV doesn't have any documentation in the SDK PDF either.)
FYI @nathan-contino

[thestumbler]

I've been doing some investigating into this problem for a different board that has the same problem (Waveshare RP2350 1.28 in Round LCD module). It's curious because the Waveshare distributed UF2 is exactly the same as the Seeed distributed one. That seemed to have been compiled back in early August, using the PR before RP2350 support was finally merged. I can reproduce a successful build myself this way, and another guy has done the same for this XIAO board.

An indeed, building MicroPython using current releases does not work on either board. Pico SDK 2.0 was being used back in August through to a few days ago. I tested yesterday with SDK 2.1, no joy. I applied this SDK PR and recompiled, still no joy. Another guy tried this on the XIAO with the same sad results.

Are we sure that this PR, while building correctly and passing the Pico SDK CI tests, actually makes the XIAO board boot up into MicroPython correctly?

Disclaimer: I realize I'm that I'm comparing two completely different RP2350 modules. It's possible that they both worked perfectly in August, and are now failing with the released MicroPython for completely different reasons. While I don't have a XIAO to test with myself, I've asked someone else to test this, with the results noted above.

While there may be a good reason for changing the SPI clock speed per this PR, I think there may be more fixes needed before MicroPython can run on the XIAO (and perhaps Waveshare) modules.

Since the focus here seems to be on the flash memory, I'd like to compare the part numbers, but Seeed hasn't released which chip they're using (and it's underneath a metal shield so not easily discerned by inspection). Knowing the part number might help track down this issue, @Lesords

[briskspirit]

@thestumbler just build micropython with both PRs picked from @Lesords and it works on XIAO RP2350, so indeed SPI clock needs to be lower for flash chip Seeed chose

[briskspirit]

@lurch any chance this PR can be merged?

[thestumbler]

Oh. There's a second PR? I missed that

[thestumbler]

Where is this second PR? I only see one under @Lesords user, that's here on the Pico SDK, and none on the MicroPython repo. Am I missing something obvious?

[briskspirit]

Second PR is just a board definition, standard Pico 2 should work. But make sure that you select target, iirc by default rp2 port builds for rp2040

[thestumbler]

So, I'm still confused about the SPI clock speed. Back in August, when one could build MicroPython successfully for the XIAO, using the stock SDK 2.0, wasn't the SPI running at the same "fast" speed that now doesn't work and needs to be halved?

[thestumbler]

I already have that PR, it's only one file that cigs the SPI frequency in half. Where is the second PR? And yes, I am correctly selecting the 2350 board. Good point! I've done more stupid things before.

[Lesords]

Where is this second PR? I only see one under @Lesords user, that's here on the Pico SDK, and none on the MicroPython repo. Am I missing something obvious?

Here: micropython/micropython#16299

[Lesords]

So, I'm still confused about the SPI clock speed. Back in August, when one could build MicroPython successfully for the XIAO, using the stock SDK 2.0, wasn't the SPI running at the same "fast" speed that now doesn't work and needs to be halved?

No, the SPI frequency of the firmware compiled at that time was always 50Mhz

[lurch]

@lurch any chance this PR can be merged?

a) I don't have merge permissions on this repo
b) most of the Raspberry Pi engineers (including myself) are currently on Xmas and New Year holidays 🎄 🎊

[lurch]

@will-v-pi / @kilograham A thought that I had this morning: if a particular (RP2350-based) board will always need a boot_stage2 to be included (which is what the comments in this PR seem to be implying?), is there a way for that to be done from the board's header-file?

[mattytrentini]

FWIW I've been testing MicroPython for the XIAO RP2350 with this change and it's been working fine. Looks good to merge, to me.

Note that if you're trying to build MicroPython it will involve combining two PR's (#16299 that defines a MP board to use the pico-sdk seeed_xiao_rp2350 definitions and then this one to modify the clock rate for that definition).