WIP: Hackathon Board

[JuliDi]

This PR adds the KiCad files for our hackathon board design.

I will add more description on the go.

Right now there are a few things still missing, but if anyone (esp. @joelsa) wants to have a look and point out any mistakes/bad design patterns etc, that would be great.

Resources

• Raspberry Pi Debug Probe Schematic and firmware
• RP2350 Datasheet
• Bosch BME690 Datasheet

[joelsa]

Nice, I took a quick look, looks good!

Some remarks:

• I tend to rotate the local labels so they are on the line, making it clearer where they belong to:
  to
• SSD_SCL and SSD_SCA are missing a strong pull-up, maybe 10k to 4k7, something in between
• BME_SDO and BME_CSB are not yet connected. The datasheet says SDO selects the I2C address and must be tied to GND or VDDIO, not left floating. Of course it could also be connected to a GPIO of the RP2354B, then I would add a pull-up or pull-down resistor to create a sane default.
• The USB connector has a weird and not fitting footprint assigned: Package_LCC:PLCC-84_29.3x29.3mm_P1.27mm. A good footprint is Connector_USB:USB_C_Receptacle_HRO_TYPE-C-31-M-12. It is a 17ct USB-C connector (https://www.lcsc.com/de/product-detail/C165948.html) and the footprint is compatible with more expensive connectors from both Würth and Molex.
• PG is a hierarchical input pin in the buck_3v3 subschematic, should be an output pin
• Decoupling caps are missing, I would add 1x 1u + 2x 100n (for both VDD and VDDIO) to the BME690. For the RP2354A, the decoupling scheme suggested in the datasheet is essentially this: with 1 capacitor placed at every power pin.
• Library OnMCU_Inductor_SMD is unavailable (contains the inductor footprint for L1)
• The main advantage of the TPS62177DQC Buck converter is the high input voltage of 28V, but since we will power this board from 5V USB-C, we don't need that. Murata has buck converters with inductor-in-package, e.g. https://www.digikey.de/short/5dzhm387. More power for half the price of the TPS62177DQC solution inside a single component. (1 USD for the MYRBP330080B21RD vs 2,20 USD for TPS62177DQC + Inductor).

[joelsa]

• D+ and D- are swapped at the top level:

• USB is missing series resistors for series termination, Raspberry Pi specifies 27 R (Section 5): https://datasheets.raspberrypi.com/rp2350/hardware-design-with-rp2350.pdf, I'd follow that directly:

• SDA and SCL are swapped on the RP:

• Both Pull-Ups are connected to SDA, one needs to go to SCL:

• Local decoupling caps are still missing, there are about 20 capacitors missing (10 for each RP2354). I'd also add 2x 100 nF (1x VDD, 1x VDDIO) decoupling to the BME690.

• There are very weird footprint assignments: C201/C202 have some DC/DC-converter footprints, R102/R103 and several other resistors have DIP-8 footprints; J301 has a DIP-20 footprint.

• R203’s resistance is specified as "R", which value should it have?

• Why is the AT42QT1070-M in there, do you plan on adding that as well?

Regarding the debugger questions:

• Yes, U301 RUN should be separate from the reset button, but connected to J301 for programming/recovering the debugger itself. U301 GPIO1 -> R102 -> U102 RUN is correct to reset the target.
• Debugger BOOTSELF: Yes, I'd add it, this way the debugger can be reoverd via USB without another probe.
• For pins:
  • The official debug probe uses GPIO12 for SWCLK, 14 for SWDIO write and 13 for SWDIO read. This is done for level-shifting, so it's 5V compatible. I think we don't need that, since our board will run on 3V3 only (but I still would break-out the SWD interface on a 2.54 mm Pinheader so that participants can use it to debug other boards). They then use this config: https://github.com/raspberrypi/debugprobe/blob/master/include/board_debug_probe_config.hinclude/board_debug_probe_config.h I think for us it would make more sense to use the pico as a debugger config and move SWCLK to GPIO2, SWDIO to GPIO3, RUN to GPIO1, that way we can reuse the pico configuration: https://github.com/raspberrypi/debugprobe/blob/master/include/board_debug_probe_config.h with the PROBE_IO_RAW mode.
• Regarding schematic organization:
  • I think the LED sub-sheet is fine. I don't really like these KiCad Buses where you can route ten signals at once in the schematic editor as they hide what's really going on and often lead to naming errors etc. Since not all of our participants might understand the concept of an active low LED, maybe add a note there that says "LEDs turn on when the GPIO is low"?
  • Some local labels have the same name, like SWCLK. Not an issue per se because they are local labels, but makes it harder to search for, I'd name them TARGET_SWCLK, DEBUGGER_SWCLK
  • I think the display and LEDs and Sensor could even be moved to a subsheet to keep the top-level sheet cleaner. Then we can add the peripheral headers there as well.
  • I think I'd switch the display to just a 1x4 pinheader with no custom symbol or footprint, this is more understandable for the participants I think
  • I like that there are no four-way junctions, these make it impossible to see if one of them is slightly off-grid and not connected properly
  • For cleanliness, I always make sure the length of any wire section is at minimum two grid steps with 50 mil, so 100 mil in total or a multiple of that (100, 200, 300)
  • I always use k for kilo and not K in order to not confuse it with Kelvin

[JuliDi]

• Local decoupling caps are still missing, there are about 20 capacitors missing (10 for each RP2354). I'd also add 2x 100 nF (1x VDD, 1x VDDIO) decoupling to the BME690.

They are missing on the debugger atm, but what about the ones on the main sheet?

[JuliDi]

• R203’s resistance is specified as "R", which value should it have?

I guess this very much depends on the LED :D Any recommendations for what LEDs we should use? (for the RGB I found one from Würth that looks good, but we dont have to use that, happy to use a different one)

[joelsa]

I guess this very much depends on the LED :D Any recommendations for what LEDs we should use? (for the RGB I found one from Würth that looks good, but we dont have to use that, happy to use a different one)

I like the Würth components, good documentation and they behave to spec.

For resistance: I usually do 330R, 470R or 1k, depending on how bright it should be, usually 1k is enough brightness already. But there are some green LEDs that have 3.3V forward voltage so with 1k they are really dim if powered from 3.3V.

[JuliDi]

I think then 470 and a green LED might be fine for the power indicator.

Edit: actually, not how it is wired right now. It is connected to V_BUS and not V_OUT. (The latter would make more sense: it also indicates "no power" when USB is plugged in but the voltage regulator is fried)

[JuliDi]

I am thinking about using 150060VS75000 (green, Vf = 2V) as a power LED and then either 150060BS75000 (blue, Vf = 3.2V) or 150060RS75000 (red, Vf = 2V)

This also depends on what color our solder mask will be. From what I see on Eurocircuit's website, they can do Green, Black, White, Red, Blue (and transparent or "PCB PIXture" – looks fancy).

And I'd imagine a blue LED on a blue PCB looks a bit ugly, while blue LED on a black PCB gives a nicer contrast than RED. And from what I see on this page https://rp2350b.pinout.xyz/ all the GPIOs that connect to the LED strip have PWM, so dimming shouldn't be an issue.

Let me know what you think :)

[joelsa]

I am thinking about using 150060VS75000 (green, Vf = 2V) as a power LED and then either 150060BS75000 (blue, Vf = 3.2V) or 150060RS75000 (red, Vf = 2V)

Yeah, these sound nice!

They have wildly different efficiencies though (red 6x more mcd per ma than green) so in order for them to have roughly the same perceived brightness I would choose 3k3 for red, 680R for green, 330R for blue. That should work out to approx. 3-5 mcd per LED which is clearly visible but not blinding. It's hard to know for sure because the "current to perceived brightness" curve is highly nonlinear, but it willl work out.

[JuliDi]

@joelsa as discussed in chat, we want to add a second USB receptacle for the application processor. This requires a bit more sophisticated setup, for which you already have an idea.
Also, we need to determine which part we want to use for the USB receptacle, e.g., Würth 629722000214