Arduino Boards Manager

When installing v 2.7.2 of “Seeed Xiao RP2040” into Boards Manager I am receiving the following error…
“CRC doesn’t match, file is corrupted. It may be a temporary problem, please retry later.”

Sorry, it’s a problem with our server, we’re fixing this, please wait.Sorry, it’s a problem with our server, we’re fixing this, please wait.

… this was 9 days ago … and still we have CRC error … :neutral_face:

Guglielmo Braguglia

1 Like

Version 2.7.2 only fixes the compatibility problem between XIAO RP2040 and XIAO expansion board, it is still in testing stage, we suggest you use version 1.12.0 first.

1 Like

The problem has been fixed and is working properly.

1 Like

I can confirm that OLED on the XIAO expansion board works with an XIAO RP2040 using version 2.7.2 of the board package.

Here’s my basic test using the U8g2 library (Same as first attachment)

   XIAO RP2040 test of OLED on the Seeeduino SIAO Expansion board
   Patterned after the u8g2 library HelloWorld example

   This works with Seeed XIAO RP2040 board package 2.7.2
   Note the board type in the u8x8 constructor below.

    April, 2022

#include <U8g2lib.h> // In U8g2 library 

// Seeed Expansion board uses SSD1306
U8G2_SSD1306_128X64_NONAME_F_HW_I2C u8g2(U8G2_R0, /* reset= */ U8X8_PIN_NONE);

// My breadboard has an SH1106
//U8G2_SH1106_128X64_NONAME_F_HW_I2C u8g2(U8G2_R0, /* reset=*/ U8X8_PIN_NONE);

void setup(void) {
  // Change #if 0 to #if 1 to print some stuff
  // If you do, it will wait until you open the Serial Monitor
#if 0
  while (!Serial) {}
  Serial.println("\nOLED u8g2lib test compiled on " __DATE__ " at " __TIME__);

char printBuffer[30];
uint8_t passno;
void loop(void) {
  snprintf(printBuffer, sizeof(printBuffer), "            Pass %3d", ++passno);
  u8g2.clearBuffer();                   // clear the internal memory
  u8g2.setFont(u8g2_font_ncenB08_tr);   // choose a suitable font
  u8g2.drawStr(0, 10, "   Hello XIAO RP2040!");
  u8g2.drawStr(0, 30, printBuffer);
  u8g2.drawStr(0, 50, "Best regards,");
  u8g2.drawStr(0, 63, "davekw7x");
  u8g2.sendBuffer();                    // transfer internal memory to the display

Also tested u8x8 from the u8g2 library and the real eye-catcher from the Adafruit_SSD1306 library.

Unlike previous versions of the XIAO RP2040 board package, these all work with no changes to any Seeed files or any of the libraries that I tested.

Bottom line:
Huzzah! (But I said that already).


Dave (1.1 KB) (2.4 KB) (3.4 KB)

Yes, this version of the update is mainly on top of the compatibility issues with the expansion board, we will continue to follow up.

Although I verified that changes make an I2C interface work as expected, that’s not the end of things.

I now discover that the SPI stuff is totally borked.

Lines 71-75 of pins_arduino.h for the XIAO RP2040 variant look like this:

// SPI
#define PIN_SPI_MISO  (16u)
#define PIN_SPI_MOSI  (19u)
#define PIN_SPI_SCK   (18u)
#define PIN_SPI_SS    (17u)

Now, GPIO pins 16-19 aren’t brought out to the XIAO header, so this could never work. The SS can be reassigned by the user when invoking SD.begin(), but the other stuff is fixed in the SPI interface software.

I modified the arduino_pins.h and I modified my SD test program from a previous thread so that I could test a microSD card plugged into my XIAO Expansion Board, which uses PIN_D2 as the Chip Select for the SD Card.

Comments from the attached example:

 * As of April 6, 2022, The Seeed XIAO RP2040 Board package, version 2.7.2,
 * has incorrect assignments for PIN_SPI_MISO, PIN_SPI_MOSI, and PIN_SPI_SCK,
 * with the result that SPI functions will not work.
 * I changed lines 71-75 to make assignments consistent with XIAO RP2040
 * pinout diagrams.

Here are those lines in the distribution
// SPI
#define PIN_SPI_MISO  (16u)
#define PIN_SPI_MOSI  (19u)
#define PIN_SPI_SCK   (18u)
#define PIN_SPI_SS    (17u)

To get SPI to work as expected and as indicated on the 
XIAO RP2040 pinout diagram, I changed those lines to

// SPI
#define PIN_SPI_MISO  (4u) // davekw7x: PIN_D9  --- was (16u)
#define PIN_SPI_MOSI  (3u) // davekw7x: PIN_D10 --- was (19u)
#define PIN_SPI_SCK   (2u) // davekw7x: PIN_D8  --- was (18u)
#define PIN_SPI_SS    (1u) // davekw7x: PIN_D7  --- was (17u)


Bottom line: I guess that, when the Seeed guys copied the mbed Raspberry pi pico file to the XIAO rp2040 pins_arduino.h, they forgot to check the SPI pins.

I attached my SD test sketch in case anyone is interested. This is the same as the sketch that tested the XIAO, with the only significant change that uses PIN_D2 as the chip select. The output from this one looks like the one in the other thread.

Original XIAO sketch is here:


Dave (2.2 KB)

1 Like

Sorry, I’m not a XIAO developer, but I’m interested in your feedback. Something I don’t quite understand, is the reason you changed the pins here that XIAO can’t use the SD card on top of the expansion board? Or is it for some reason?

I tried to explain, but maybe something got lost in the verbiage, so here goes again:

The SPI pin assignments in release 2.7.2 are for CPU GPIO pins that are not brought out to the XIAO RP2040 header.

These assignments are used in the SPI software for this board, and can not be changed in a user sketch. Therefore, the SPI library can not work with this board package, no matter what connections you make to the XIAO RP2040. Period. Full Stop.

I made assignments consistent with the XIAO RP2040 pinout diagram, which I attached to my previous post, and then the SPI stuff worked.

My development is usually on solderless breadboards or other (custom) prototype hardware, but I tested this on the XIAO Expansion board so that the good folks at Seeed could easily reproduce the problem and my proposed solution. (See Footnote)

I have attached two screen shots: The first is with the unmodified 2.7.2 Board package. The second is a run after modifications that I showed in my previous post.

The runs were with an XIAO RP2040 and with a freshly formatted 16 GByte uSD card plugged into the XIAO Expansion Board.

I have also attached the sketch that created these outputs. It is a modified version of the CardInfo example from the SD library. (Only modifications other than chipSelect value are printouts of SPI pin values.)



The “interesting” thing for me is that Board release 1.12.0 had correct SPI assignments, but the I2C stuff didn’t work. Release 2.7.2 has corrected the I2C stuff (not just arduino_pins.h, but other I2C stuff as well), but somehow managed to screw up the SPI.
[/Begin Rhetorical Question]
Isn’t there some kind of regression testing? Or at least some kind of review by someone other than the developer making changes?
[/End Rhetorical Question]
Oh, well… (66.2 KB)

Thanks for everything, I’ll take the time to test it out.