Support for Raspberry Pi RM2 wifi / ble module

[anecdata]

Would need CircuitPython API to select the MCU pins to use.

We also may want to consider adding ssl to boards with enough resources that would not ordinarily have it (this would also expand the set of boards that could use WIZnet ethernet as an SPI peripheral with ssl).

I don't see mention of this module on the Raspberry Pi site, but it is incorporated in 3rd-party products, for example @pimoroni RM2 breakout and Pico Plus 2 W.

Related:
CircuitPython Bump cyw43-driver module to v1.0.4 plus to match SDK 2.0.0. #9775
MicroPython Support for RM2 break out boards #16057

[eightycc]

The RM2 module incorporates the same mux'ing of its DI, DO, and IRQ pins as the Pico Plus 2 W so building a CP board port for a Pico Plus 2 board with the module SP/CE attached should be straightforward.

Of course that approach leads to a proliferation of board ports, so some means of separately supporting RM2 might be a good thing.

[eightycc]

Pico SDK 2.0.0 hard codes the pin numbers used for the CYW43439 gSPI interface, so changing CYW43_PIN_WL_... will have no effect. The develop branch of the SDK corrects this.

[dhalbert]

Are there boards that need the pin numbers to be changed? Or can we wait for the pico-sdk changes to be put in a release? We can move up the submodule commit if necessary.

[eightycc]

@dhalbert All of the RP2350 boards that include an RM2 that I've looked at follow the RP2040 Pico W pin assignments so they are not affected. It does become an issue with RM2 breakouts. For example, the Pimoroni Pico Plus 2 attaches an RM2 breakout with its SP/CE connector that utilizes pins 32, 33, 34, 35, and 36.

I do not recommend switching to the SDK develop branch at this time. I tried it and got stuck in build issues.

Release SDK 2.1 has no build issues.

[eightycc]

Pico SDK 2.1 corrects hard-coded CYW43 pin numbers in the SDK. #9831 picks up SDK 2.1.

supervisor/port.c hard codes CYW43 pin numbers guarded by CIRCUITPY_CYW43.

[eightycc]

I've worked through removing hard coded pins so that I can build CP for an RP2040 Pico with an RM2 attached to pins 10, 11, 12, and 13. It runs, but the RM2 fails to initialize. Hooking up a scope while reducing the SPI clock to 625kHz reveals something interesting.

The SPI clock phase for the RP2040 to RM2 is as expected, bits are output on the falling edge of the clock. However, the RM2 is outputting bits on the rising edge of the clock which is causing words read from the RM2 to be off by 1 bit. RM2 clock phase is controlled by the "High-speed mode" bit of the gSPI config register which should default to 1 (sample and output on rising edge of SPICLK), after reset, but instead is behaving as if it is defaulting to 0 (sample on SPICLK rising edge, output on falling edge). It appears that the RM2 default differs from the bare CYW43439 used on the Pico W.

Digging into the SDK's CYW43 driver code, I find that the order of operations to initialize the CYW43/RM2 is incorrect. The driver code first attempts to read the CYW43 test register, then it writes the config register. This worked with the CYW43439 default, but fails with RM2 default. According to the CYW43439 data sheet, the driver should be first writing the config register, then polling the test register.

[anecdata]

I hadn't noticed until now that the tins were different between PicoW / Pico2W (both blank), and the RM2 (FCC labeling). MicroPython presumably would have also encountered this (?) but I don't spot a mention of SPI in their PR (16057).

[eightycc]

There could be different versions of the RM2 floating around? The one I'm testing with is from Pimoroni and does have FCC markings. An aspect of working with the CYW43439 and RM2 that adds difficulty is that the old Cypress Semi data sheet is incomplete and diverges from the actual parts. I read through 16057 again and there is mention of stability problems with an RM2 breakout. The closest the issue comes to pointing at gSPI is adjustment down of the CLK, presumably to compensate for signal degradation.

My next testing step is to modify the driver to try both falling and rising clock edge phasing while reading the test register. If that works, then I can dump the RM2 gSPI registers to see the actual defaults.

[eightycc]

Here is a screenshot illustrating the phase error for an RM2 response to a read of the gSPI test register:

Yellow: CLK
Cyan: DO
Magenta: CS

[eightycc]

Clearly someone else has been here before. By changing the PIO program to spi_gap0_sample1 the RM2 functions as expected. I think the comment "for lower cpu speed" should read "for lower gSPI clock rate". It appears that the CYW43439 and RM2 have some sort of gSPI clock speed detection that governs the selection of clock/data phasing. Looks like I've got a Pico SDK issue in my future.

https://github.com/raspberrypi/pico-sdk/blob/95ea6acad131124694cda1c162c52cd30e0aece0/src/rp2_common/pico_cyw43_driver/cyw43_bus_pio_spi.c#L33-L42