After quite a long break I decided to take a look at the old v06x-tiny project with the tiny keyboard. I put it aside out of frustration 2-3 years ago. Who knows what you can see with a fresh look.

On the power-on not much has changed. Keyboard seems to work, SD card seems to kinda work maybe 1 out of 4 times, then fails quickly anyway. 

Recompiled both the esp32s3 host and rp2040 keyboard. Both needed a bit of a makeover due to SDK updates.

All good, but now it doesn't work pretty much 100% of the time. I still don't know if it's a random fluke or something in the updated SDKs.

I frequently hear about people using logic analysers but I never had a use for one. Isn't it the perfect time for one now! There are two different rp2040-based logic analysers. One is called sigrok-pico, another is called "LogicAnalyzer" by gusmanb. With both I had trouble making them work on Linux aarch64, both worked fine on Windows. I expected this to be exactly the opposite, but it's ok. After some trial and error I settled with LogicAnalyzer because it seemed a bit more direct. Because I have one board with all 3V3 logic, level shifters should not be necessary.

Probing the bus helped me remember why I wrote some angry things in the code, and even angrier things in code comments back then:

What we're seeing here is probably the reason why we don't see many implementations of SPI Slave devices based on RP2040. The hardware peripheral can't handle MISO swichover on SS, and programmatic switchover takes time. This makes me lose first 4 bits in front of every response and adds a fairly long delay in MISO switchover to high-Z after SS goes high. This delay probably causes more conflicts with SD peripheral when it's active.

Update

SPI switchover solution: PIO SPI SLAVE

Builtin peripheral cannot switch MISO pin direction automatically, this has to be done programmatically and there's a great delay attached to that. It can be done with PIO though.

I'm not sure why implementing PIO based SPI slave was so hard, it seems like a trivial thing now. Several mistakes that set me back a day or three:

• I sampled SS level instead of edge. Fix: sample SS edge.

• wait on clock transition without bit counting, expecting the transaction to end by SS going high, but SS-going-high detection code would not execute because the code was stuck in wait clock. Fix: count bits and end transaction when 16 bits shifted out.
• autopull, but sometimes the fifo would be drained mid-transaction ~ still unsure how it works. Fix: explicit blocking pull at the beginning of transaction

It seems that implementing a properly robust SPI slave is still a hard task even for the mighty PIO. Maybe this is why you don't see many PIO based SPI slaves out in the open. Now I have one. 

SPI electrical issues

However after seeing nice and clean keyboard transactions in the analyzer I still had SPI errors. After some testing and shifting blame between various things I singled out the CLK wire going to the keyboard. Apparenly it's too long and twisty and simply connecting it distorted communication with SD card. 

The fix: 120 ohm series resistor at the connector. Minimal surgery:

And hoorj! The keyboard + sdcard work together. 

Core takeaway: taking a 2 year break is sometimes the most productive thing you can do.