Assembly and first results (and first mistakes)

This commit is contained in:
2026-08-01 13:37:52 +02:00
parent 81729ff39e
commit 51d6ae0c19
16 changed files with 292925 additions and 14 deletions
+65 -10
View File
@@ -2,10 +2,11 @@
Cacao is a compact 12-channel audio-frequency signal-acquisition board built around the RP2350. It explores how modern, accessible components can consolidate multi-channel acquisition, buffering, storage, and Ethernet communication onto a single 80 x 50 mm PCB.
![CACAO Board](figures/Assembled.jpeg)
![Cacao PCB - 3D render](figures/Recto.png)
![Cacao PCB - 3D render](figures/Verso.png)
<!-- Replace docs/images/cacao-render.png with the final board render. -->
(On the real pic you can see pretty obvious shorts on different chips, the board was just out of the oven and the shorts were dealt with before first bring up)
## Overview
@@ -38,17 +39,51 @@ An alternative future configuration could replace the W5500 and external RAM wit
The firmware will have to be as efficient as possible to allow 10-12 channels at the same time to be sampled and transferred to the W5500.
## Assembly
V1's PCB's were manufactured by the company Aisler. It was a first test for me and I liked the service a lot.
PCB's arrived naked and I assembled three prototypes by hand at school where we have small manually controlled "pick and places" machines that help speed up the process of compared to using tweazers to place components.
![CACAO Board](figures/Bare_PCB.jpeg)
![CACAO Board](figures/Compare.png)
On the top you can see the bare PCB and on the bottom you can see a fully assembled board next to the boards she is supposed to compete against. (The others are blurred as they are property of the company I worked in but they are the boards that are doing 12X less work as cacao does)
## Project Status
V1.0 is currently being assembled by myself and testing will soon start.
V1.0 has been received and assembled. It is currently in testing but I can already say that :
+ All power buses are operational
+ Ethernet works with PIO SPI instead of native SPI
+ RP2350 can be flashed using the USB and SWD
+ All ADC's are working and be communicated with
+ After modifiying the micro USB connection data can be read from ADC's to the Rp2350 and then to USB or Ethernet
So basically all the main features are working.
Here is what cannot be tested
+ The RAM has not been installed as all of its wiring is wrong and a PIO implementation could work but not fast enough for my use case so it will need to wait for a new version
+ The SD card port was not received
Here is what is still in testing
+ Actual throughput limit through the W5500 with the reduced SPI bandwidth
+ Quantifying the signal integrity coming from the analog capture. (it is looking pretty good on my first tests)
## known V1 issues
There are a few problems with the V1 of this PCB and they are pretty serious so I would advise not to send any of these files to be produced and to either modify these mistakes or to wait for a V1.1 or V2 of this board.
The first version as always has problems and here are the known issues that will be fixed in version V1.1 or V2 depending on how much changes are needed after the full testing of V1 goes.
### Bad selection of Rp2350 ports
This is the most embarassing problem of them all. I put a bit too much faith in the MUX capabilities of the rp MCU and choose the SPI and QSPI pins incorrectly.
That is a pretty embarassing issue but it is not fatal. I put a bit too much faith into the internal GPIO MUX of the Rp2350 and did not respect the rules about SPI pin selection.
First of all, all pins of a SPI bus need to be connected to the same SPI port, but there only are a few pins that are actually connected to a SPI port and even then not all of these pins can be used for everything. You cannot put MOSI or SCLK on any pin of the SPI port.
Also an other issue, QSPI cannot be rerouted to any pin. The QSPI bus is only available from the QSPI specified pins which is something I missed unfortunately for the external RAM.
The RAM needs to be totally rerouted, 5/6 pins are wrong and need to be changed :
@@ -62,9 +97,7 @@ RAM_QSCLK not to GPIO 20 but to QSPI_SCLK
This is extremely embarassing as the pins are even labeled, I should have seen this before sending the files to production.
The W5500 and SD CARD are wired wrong too as even if the selected pins are correct, not all pins of a SPI bank can do every job.
So you have to do these swaps :
The W5500 connection needs to be rerouted as such :
```
ETH_CS GPIO28 to GPIO29
@@ -72,8 +105,30 @@ ETH_SCLK GPIO29 to GPIO30
ETH_MISO GPIO30 to GPIO28
```
And for the SD card its all wrong as I did not plan for SPI0 and SPI1 differences.
And for the SD card it's just completely wrong.
I would advise not to botch anything but rather use a PIO SPI that then can be used on pretty much any pins.
Thankfully these issues do not prevent testing as the PIO blocks can be used to create homemade SPI with custom pins, but performances will not be as the same level as they would have been with native SPI. That is why on the first batch, the RAM was not even soldered as it was not very useful to use even with PIO in my use case.
Those mistakes are extremely embarassing but they exist and will have to be dealt with when assembling the boards.
### Wrong micro USB pinout
This one looks stupid too but actually is not that ridiculous. It could have been avoided but it is not completely stupid.
The préamp that is supposed to be plugged into the cacao board is a custom solution that only uses the micro usb port and not protocol or guidelines.
During the design, I put 5V on the VBUS pin and GND on the GND pin. How foolish of me to not check that the designers of the AMP might have wired it completely differently putting 5V on the GND pin and GND on pin 4...
So all 12 channels actually are not powering the pre amp and are getting a signal that is waaaay too weak to be used.
A test was done by removing one port and wiring a new port with botch wire in the right order and then it worked perfectly.
So for a new version you would have to make these changes :
```
uUsb Pin 1 VBUS -> GND
uUSB Pin 4 NC -> GND (the actual GND used by the preamp)
uUSB Pin 5 GND -> 5V
```
It took longer that I want to admit to diagnose this as the signal was not truely 0. I was just getting a very weak signal but tapping the mic still gave some signal. And of course the preamp has no power on LED or anything.
But for now it looks like the only issues of V1 are pin assignement and that with those sorted the all system should work perfectly and with much better performance.