RP2040 M.2 Pico

For whatever reason (which I will find out later) I could not make the SD card work on the SPI1 port of the RPi Pico with (CS=GPIO13, CLK=GPIO10, MOSI=GPIO11, MISO=GPIO12).

So I did some re-wiring and used the standard SPI port with the pin mapping as follows:

#define SD_CS         17
#define SD_DI         16
#define SD_DO         19
#define SD_CLK        18

// uSD card
SPI.setRX(SD_DI);
SPI.setCS(SD_CS);
SPI.setSCK(SD_CLK);
SPI.setTX(SD_DO );

 This approach worked flawlessly and I could do all the file system commands provided by the SD.h library.

A simple speed test did show sufficient performance for basic data logging:

SD Card Speed Test...
Writing to byte.txt...done.
Duration [millisec]: 10377
FileSize [bytes]: 1048576
Write Speed(8bit) [KByte/sec]: 102
Writing to 16bit.txt...done.
Duration [millisec]: 15828
FileSize [bytes]: 2097152
Write Speed(16bit) [KByte/sec]: 136
Writing to 32bit.txt...done.
Duration [millisec]: 28910
FileSize [bytes]: 4194304
Write Speed(32bit) [KByte/sec]: 146
done

The write speed vary for the 8bit test from 97 to 128 KB/sec and for the 16bit test from 120 to 136 KB/sec. The 32bit test is very stable at 146 KB/sec.

As mentioned earlier, the SPI interface signals of the uSD card slot are connected backwards.

SCK <-> CSn

MOSI <-> MISO

This means 4 cut traces and 4 wires. In the end nobody will know because the wires will be hidden under the SD card holder. Just a few pictures to document the process:

Cut trances and wires already attached. I used 38 gauge magnet wire, which is perfect for this kind of re-work as the insulation melts away. No wire stripping required.

Then the wires got nicely covered with Polyimide for protection

And the uSD card holder soldered to the board.

Next, a trip into software land and trying to talk to the uSD card. I am going to try the Arduino SD library and [Greiman]'s SdFat library. I learned already that the maximum size for FAT32 file-system is 32GB, everything larger needs to run with exFAT. I will find out soon.

Since a long time I had the idea to simulate castellated pins on a board edge to get around the pricey options to do it as intended by your PCB house of least suspicion. My idea was to have the PCB outline indented by half circles and add a curved pad on top and bottom connected through one or more vias. Wires or pin headers could be soldered to either pad. To solder the board on a prepared carrier footprint ( ESP32 module style) would probably need some extra wires, but that was not the intend of this board anyways. 

Here is an image how the 2 pad styles look in KiCAD (please ignore the silkscreen, this layout was far from finished). I probably could have moved the half pad closer to the board edge.

 After receiving the boards, I tried to solder pin headers to the pads and ran into several problems. The board was only 0.8mm thick, so there was not much support. With the plastic body on one side, I did solder only the opposite pad to the pin which did not give enough strength. I tried to use hot glue to fix the connector to the board but still managed to rip off pads very easily. Some more pictures of the whole mess.

Overall it was more pain than useful. I would give this idea a -1 out of 11, would not recommend. 

As it happens too often, this revision 1 board has its issues. With my RadXA ROCK 3A SBC not arrived yet, I was going for the fly-wire test approach.

USB and power through an external 3.3 V regulator are working flawlessly. Power LEDs are on and the user LED is blinking away. Nice! UART on the m.2 and on GPIOs are doing simple loopback and the USB/UART is running a simple command line already.

Things that did not work out of the box: I2C (of course). I should pay more attention to the pin mapping. I cannot use I2C1 at the same time on the m.2 and the QWIIC connector. Also pin4 on the QWIIC is SCL, not SDA. Nothing a few cuts and wires cannot fix. Now I have a loop-back from the m.2 end to the QWIIC connector. One port is master, one is slave. Mint.
More wires will be required to test the uSD card, the SPI signals are connected up-sidedown to the SPI port on the RP2040. Pin mapping again! I blame this one on the schematic symbol, not showing all pin functions. 

And the castellated holes will get their own log. Some cheap ideas are also bad.