RP2350: builds do not run on a pico2 clone

[permaBox]

Port, board and/or hardware

rp2350 port, pico2 china clone

MicroPython version

mpy latest and any before

Reproduction

The rp2350 releases do not run on the pico2 clone from aliexpress.
But any circuitpython rp2350 release behaves properly and runs!

Expected behaviour

No response

Observed behaviour

After uf2 flashing no virtual com port was established.

Additional Information

pico2 clone:
https://de.aliexpress.com/item/1005008492816984.html?spm=a2g0o.productlist.main.29.1437789cVidIhs&algo_pvid=bb560c92-b1b0-4ce5-a741-61e242d2c2dd&pdp_ext_f=%7B%22order%22%3A%229%22%2C%22eval%22%3A%221%22%7D&utparam-url=scene%3Asearch%7Cquery_from%3A

Code of Conduct

Yes, I agree

[projectgus]

@permaBox It's not really possible to support unbranded clone boards fully - it's a total dice roll what you get, and even if I order the same board from the same seller tomorrow then it could have slightly different hardware on it if the vendor is using the cheapest possible parts (flash, oscillators, capacitors, etc) that are available on the market that day.

If it's not too late then you may be able to claim a refund from aliexpress because the board isn't actually a compatible clone (as evidenced by it not working).

On the other hand, if you are able to figure out what would need to be changed in MicroPython to support this board then we can consider the change, if it doesn't impact performance or other functionality. However, you'll need to do this technical work to figure that out. Sorry we can't be of more help.

[DavideRossi]

I have that clone. It works fine with the FW for the SEEED_XIAO_RP2350 board.

[GitHubsSilverBullet]

may still corrupt one in every billion SPI transfers,

That'll happen anyways, the question is not ›if‹ or ›may‹, it is ›when‹
No matter how well designed a system is, whether it runs perfectly within the given boundaries, it'll fail eventually. On the other hand, there's very little reason to run various parts at frequencies far below their specs.
What's more important IMHO is an easy way to configure those parts without rebuilding the binaries. The system could start at a slow enough speed until it is able to read a config file with the important fine-tuning (per FLASH chip docs) parameters. If nothing is there, it'll stay at the safe speed.

[Gadgetoid]

It probably wouldn't hurt to benchmark the performance difference on RP2350 / Pico 2 at "unconfigured" (rom bootloader) default, a ~50MHz safe value, and the fastest we can push the Pico 2 before it melts.

As much as raw flash speeds are enticing, if there's no significant impact to performance (our reason for the dynamic flash timing change was adding overclocking headroom by keeping the flash speed consistent, IIRC we weren't interested in the flash performance itself) then the solutions here are academic and we should just set MICROPY_HW_FLASH_MAX_FREQ to ~50MHz for Pico 2.

For the edge cases (where you really want flash performance), the vendor (or hobbyist) can just configure MICROPY_HW_FLASH_MAX_FREQ to their preference and/or load a C module (or use some clever Python and uctypes) to configure specific flash timings.

[shariltumin]

The name of the MICROPY_HW_FLASH_MAX_FREQ flag is unfortunate since it has nothing to do with actual speed. It is used in "rp2_flash.c" to calculate the flash divisor.

If we are running at 150Mhz, the QSPI speed will be 150Mhz/divisor. The way the divisor calculation is set up, related to MICROPY_HW_FLASH_MAX_FREQ and PICO_FLASH_SPI_CLKDIV, gives us the lowest divisor of 2. This gives us the maximum QSPI speed of 75Mhz.

The default speed is 150Mhz and divisor value is 4. The default QSPI speed is 37.5MHz.

With MICROPY_HW_FLASH_MAX_FREQ set to 60Mhz we will get a divisor of 3, which gives QSPI speed of 50Mhz.

Sorry for the misunderstanding in my earlier tests.

I tried pushing the speed up to 200MHz and setting the divisor to 2, which gives a flash speed of 100MHz. However, the board will not boot, and the highest practical value is 75MHz.

I tried flashing the Seeed XIAO RP2350 onto the Tenstar Red Board, and it worked. The QSPI speed is 37.5 MHz, the default value.

[Gadgetoid]

The name of the MICROPY_HW_FLASH_MAX_FREQ flag is unfortunate since it has nothing to do with actual speed. It is used in "rp2_flash.c" to calculate the flash divisor.

Agreed, very much an effort to make the best of a bad situation.

MICROPY_HW_FLASH_MAX_FREQ effectively lets you encode the datasheet maximum somewhere, and expect that it is not exceeded, but it does not (and I had, of course, completely forgotten this) guarantee the flash will ever hit that speed. Such is the peril of integer dividers. We ought to document this somewhere.

Since nobody (afaik) is overriding MICROPY_HW_FLASH_MAX_FREQ, it mostly just stands as a way of encoding the config authors intent - default clock / divisor - so that can be reverse engineered into a suitable divisor when machine.freq() is used to dynamically overclock the board. I don't believe there's a better way to accomplish this.

[GitHubsSilverBullet]

Just wrote a "short" assembler program to check access speed.
It accesses 1…8KiWORD arrays multiple times to make the XIP do its magic.
The attached pngs are for the rp2040 and for the rp2350.
One can clearly see that once the CPU clock reaches certain thresholds, the divider is adjusted upwards. Neither the 125/250 for the rp2040 nor the 150/225 for the rp2350 seems to be OK as per various FLASH memory datasheets. I've seen 133MHz for the W25Q16JV, 80MHz for the W25Q80,104MHz for the W25Q128FV and also for the ZB25VQ128.
So there's a good chance that the stuff is running out of spec already.

Oh, and one more thing. The lower four curves are the ones where the XIP does not 'overflow' while the upper four curves clearly torture the XIP beyond what it can do.
This in turn also shows, that the correct and best FLASH clock is of significant importance.

It just occurred to me that it might be helpful to include lower CPU clock rate.
The picture doesn't get prettier.
The rp2350 seems to slow down at as low as 75MHz for which I don't see any good reason.

[GitHubsSilverBullet]

Keep in mind that the divisor must be even for a 2040 but can also be odd for a 2350.
Thus the dynamic clock should be calculated like:

#include <stdio.h>

void test(int flashclock, int around) {
    for (int cpuclock = around-1; cpuclock <= around+1; cpuclock++) {
        int x1 = (cpuclock-1) / flashclock + 1;
        if (x1 & 1) x1++;
        int x2 = (cpuclock-1) / flashclock + 1;
        printf("%4d MHz: %2d %7.3f   %2d %7.3f\n", cpuclock, x1, (float)cpuclock/(float)x1, x2, (float)cpuclock/(float)x2);
    }
}

int main(void) {
    int flashclock = 104;

    test(flashclock, 1*flashclock);
    test(flashclock, 2*flashclock);
    test(flashclock, 3*flashclock);
    test(flashclock, 4*flashclock);
    return 0;
}

Resulting in: (first pair 2040, second pair 2350)

 103 MHz:  2  51.500    1 103.000
 104 MHz:  2  52.000    1 104.000
 105 MHz:  2  52.500    2  52.500
 207 MHz:  2 103.500    2 103.500
 208 MHz:  2 104.000    2 104.000
 209 MHz:  4  52.250    3  69.667
 311 MHz:  4  77.750    3 103.667
 312 MHz:  4  78.000    3 104.000
 313 MHz:  4  78.250    4  78.250
 415 MHz:  4 103.750    4 103.750
 416 MHz:  4 104.000    4 104.000
 417 MHz:  6  69.500    5  83.400