This design is shared as an open work in progress, not as an official or fully validated reference design. Mistakes may still exist in the schematic, PCB, or documentation. Please review everything carefully before building or using it. You experiment with it at your own risk, and I am not responsible for damage, unexpected behavior, or other consequences caused by design errors or incomplete information.
All the information below is based on the material available on March 16, 2026. New information may appear later, such as prices, documentation, availability, or tool support. The changelog will track the main updates as much as possible.
ST released the STM32C5 family, a cost-sensitive Cortex-M33 series with modern peripherals, more memory, and much better headroom than the classic STM32F103 used in the Blue Pill designs. Since the spirit of a bluepill is to be affordable/cheap, compact, have good performances, and be versatile for a large part of diy projects, the C5 could be a perfect evolution for the bluepill.
The LQFP48 version of the C5 is footprint compatible with the STM32F103, with an important caveat on pin 22, more on that later. Most of the alternate functions present on the STM32F103 are the same on the C5.
This means that the current bluepill designs are chip swappable!!!
It's also a good opportunity to experiment with this new product while improving the "original" blueprint design.
This project is not beginner-oriented. It assumes that the reader already understands the basics of embedded electronics and programming, such as
- reading datasheets and reference manuals
- handling schematic / PCB caveats when swapping MCUs
- compiling firmware for STM32 regardless of the ecosystem
- experience in designing PCBs with MCUs
A lot of the general Blue Pill knowledge still applies, but this repository is mainly aimed at makers and embedded developers who are comfortable verifying hardware assumptions instead of treating the board as a black box.
The Blue Pill is a community-driven board format, and this STM32C5 version is proposed as an open contribution rather than as an attempt to claim ownership of the concept.
The goal is to help the community converge toward a commonly accepted STM32C5 Blue Pill, while keeping track of the different ideas, trade-offs, and design decisions explored along the way. Maintaining that history is useful: it helps explain why some choices are good, and why others turn out to be less practical.
This project is therefore published with the expectation that improvements and modifications will be shared openly, so that the design can evolve in a transparent and collaborative way.
To reflect that:
- the hardware design files are licensed under CERN-OHL-S-2.0
- the documentation is licensed under CC-BY-SA-4.0
- the software, scripts, and helper code are licensed under MIT
This design should be seen as a guideline and a contribution to the discussion, not as the only possible STM32C5 Blue Pill implementation.
Note: I'm not the police, I will not track you down if the licenses are not followed :D
- document the differences between STM32F103 and STM32C5
- document the differences between the relevant STM32C5 variants
- explain what is still compatible at pinout and peripheral level
- explain what is not safely compatible
- show how to swap a Blue Pill from STM32F103 to STM32C5 with caveats
- provide some very basic bring-up code for the C5 once soldered on
- propose a revised Blue Pill-inspired PCB
- provide different BOM / population options for that revised PCB
- proving binary compatibility of existing STM32F103 firmware
- pretending that STM32F1 HAL projects will compile unchanged on STM32C5
Unless your project is extremely simple and close to bare metal, a recompile / port is the realistic path.
- refinements to the proposed PCB based on community feedback
- links to ST and third-party tooling as the ecosystem matures
- board bring-up notes and example firmware
- porting of previous small projects
- small-batch manufacturing if there is enough interest (a lot of work)
Useful feedback would be:
- Did I go too far with the number of optional features?
- Should this stay a "minimal Blue Pill" or become a "maximalist Blue Pill"?
- The naming of variants and configurations.
- Are the chosen target MCUs (
STM32C531CB,STM32C552CE/C562CE,STM32C5A3CG) the right ones? - Which options are genuinely useful on a board this small: CAN, QSPI, microSD, external clocks, buck supply?
- Which compatibility traps did I miss?
- Bug reports and schematic review are very welcome.
Note: this is my first public repo. Anything related to open source is welcome :)
The information summarized in this repository is based on ST documentation available around the STM32C5 launch in March 2026.
From the ST webpage, a nice summary is available comparing the products.
Before comparing the products, to avoid writing STM32 thousands of times, let's understand how to name it shortly, just like the F103.
Let's summarize the numbers and letters based on datasheets : DS15135, DS15136, DS15137, DS15125, DS14927, DS14928
IMPORTANT NOTE: Below is a deliberately simplified decoding and is only meant as a quick mental model. It does not describe the exact peripheral set or the exact number of instances available on each device.
STM32C5 v w w y z
| | | | └───────> U/T/P = UFQFPN / LQFP/ TSSOP
| | | └───────> B/C/E/G = 128KB / 256KB / 512KB / 1024KB
| | └─> F/E/K/C/R/M/V/Z = 20 / 24 / 32 / 48 / 64 / 80 / 100 / 144 pins
| └─────────────> 1/2/3 = without FDCAN and ethernet / with FDCAN / with FDCAN and ethernet
└───────────────> 3/5/9 = No AES (among other crypto) and feature variations
└─> 4/6/A = With AES or SAES (among other crypto) and feature variations
Looking at the STM32C5 products, there is 3 distinctive variants of the STM32C5 products. They all have a Cortex-M33 FPU at 144MHz, 8 KB instruction cache, USB FS, I3C, CORDIC, LDO supply architecture, Sleep/Stop/Standby. But the real differences are in SRAM, DMA, timers, serial fabric, analog mix, external-memory support, and security blocks.
Based on my observations :
| Variant | Price | Comment | SRAM | 2 x LPDMA | Timers | I2C | SPI | USART | UART | LPUART | FDCAN | ADC | DAC | COMP | OPAMP | Ethernet | Octo SPI | Security |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 53x/542 | Lowest | Simpler but richest in analog | 64KB | 8 chan | up to 10 | 1 | 2 | 2 | 2 | 1 | (2) | 1 | 2 | 2 | 1 | no | no | HASH + RNG (AES) |
| 55x/562 | Mid point | Less analog but more features | 128KB | 12 chan | up to 15 | 2 | 3 | 3 | 2 | 1 | (1) | 2 | 1 | 1 | no | no | no | HASH + RNG (AES) |
| 591/593/5A3 | Highest | Digital richest, Ethernet and Octo-SPI | 256KB | 16 chan | up to 17 | 2 | 3 | 4 | 3 | 1 | (2) | 3 | 1 | 1 | no | (RMII/T1S) | 1 | Richer (see doc) |
Presence of peripherals in (parentheses) depends on the STM32C5.
Personal note: I'm a bit surprised that there is no C592. As in: FDCAN without Ethernet. For small packages, that would make sense.
All GPIO positions are very close to STM32F103, except for the following pins:
Keep in mind the focus is only on LQFP48!
| Pin | F103 | STM32C5 | Comment |
|---|---|---|---|
| 1 | VBAT |
PE2 |
on bluepill = 3.3V, not usable |
| 8 | VSSA |
VREF- |
on bluepill = analog ground, acceptable for VREF- |
| 9 | VDDA |
VREF+ |
on bluepill = analog 3.3V, acceptable for VREF+ |
| 22 | PB11 |
VCAP |
A capacitor is required between PB11 and GND |
| 44 | BOOT0 |
PH2/BOOT0 |
By default is BOOT0, can be used as GPIO |
Great news! The STM32C5 LQFP48 is footprint compatible with the current bluepills. Except for pin 22.
Be extra careful with the pin 22, newly VCAP. This is the internal voltage of the circuit. Therefore, DO NOT DRIVE VOLTAGE ON PIN 22!!!. A capacitor should be added between pin 22 and ground. It can be soldered between the header pins. But the STM32C5 may work without it, though it is not guaranteed.
More details are available below in the [Design choices] and in the [Chip swap] section.
See the doc/STM32F103vsC5.xlsx sheet Package for more details on pin changes.
As explained above, the focus is only on 3 variants with basically the maximum features available. So the C542, C562, and C5A3. Check out the detailed data in the doc/STM32F103vsC5.xlsx sheet F103 AF compatibility.
This study is done for any shield designed for the blue pill.
Keep in mind the focus is only on LQFP48!
| Peripheral | GPIO | Affected functions | Comment |
|---|---|---|---|
| ADC | |||
| ADC1 | PB0 | IN8 | 🔴 Not present on any C5 |
| PB1 | IN9 | ||
| PA0 | IN0 | Only present on C5 with 2 ADC | |
| PA1 | IN1 | ||
| PA2 | IN2 | ||
| PA2 | IN3 | ||
| ADC2 | PA4 | IN4 | 🔴 Not present on any C5 |
| PA5 | IN5 | ||
| PA6 | IN6 | ||
| PA7 | IN7 | ||
| PB0 | IN8 | Present only on C5 with 2 ADC. Different channel number: IN6/IN7 instead of IN8/IN9 | |
| PB1 | IN9 | ||
| Timers | |||
| TIM1 | PA8 | CH1N | On C5 this is actually CH1/CH2, not CH1N/CH2N |
| PA9 | CH2N | ||
| TIM3 | PA6 | CH1 | Only on C5 591/593/5A3 |
| PA7 | CH2 | ||
| PB0 | CH3 | ||
| PB1 | CH4 | ||
| TIM3 | PB4 | CH1 | Can be replaced by another TIM |
| PB5 | CH2 | ||
| TIM4 | PB6 | CH1 | Only on C5 591/593/5A3 |
| PB8 | CH3 | ||
| PB9 | CH4 | ||
| PB7 | CH2 | 🔴 Not present on any C5 | |
| PB11 | CH4 | ||
| Serial / communication | |||
| I2C2 | PB11 | SDA | Only on C5 591/593/5A3 where SDA = PB12 and SMBA = PB13 |
| PB12 | SMBA | ||
| USART3 | PB11 | RX | 🔴 Not present on any C5, can be moved to PB1 |
| PB13 | CTS | Not present on 562 | |
- STM32C5 product page
- STM32C5 documentation page
- RM0522 - STM32C5 reference manual
- DS15125 - STM32C53xxx datasheet
- DS15135 - STM32C542xx datasheet
- DS14928 - STM32C551xx datasheet
- DS14927 - STM32C562xx datasheet
- DS15136 - STM32C59xxx datasheet
- DS15137 - STM32C5Axxx datasheet
A "chip swap" should be treated as a careful rework operation, not a casual drop-in replacement.
Minimum conditions:
- verify what the original board does with pin 22 /
PB11 - add the required
VCAPcapacitor - verify how
VBAT/ pin 1 is wired - verify whether the board assumes pin 44 is only
BOOT0 - check whether the analog routing around pins 8 and 9 is sane for
VREF- / VREF+ - expect to reflash through
SWDfor bring-up
Coming soon (A dedicated illustrated chip-swap section with photos and a minimal "do not fry your MCU" checklist.)
Coming soon (Based on ST tools or bare-metal programming)
Coming soon (STLINK, bootloader)
Coming soon (Something is already available on the ST fork of openOCD)
Coming soon (This section will mainly point to ST documentation)
Coming soon (Self test, hardware description)
This section is aligned with the current RevA schematic (hw/pcb/STM32C5_bluepill/STM32C5_bluepill.pdf).
Keep in mind This is a work in progress
The current schematic is no longer just a "swap the MCU" exercise. It is a Blue-Pill-inspired board with optional expansion blocks:
- STM32C5 in LQFP48
- Octo SPI : Limited to Quad-SPI. Which is already quite good. Having a QSPI NOR or QSPI PSRAM could serve some applications, even if the C5s has plenty of memory.
- Opamp : With a shunt resistor, we could measure some big currents through a motor, for example.
- FD CAN : Embed a CAN transceiver for more convenience.
- Keep the pinout : in case the
STM32F103was used with a shield. See the small difference later on. - USB-C : it is now much more common than micro USB.
- Supply greater than 5V : sometimes the bluepill gets itself in places where only higher than 5V sources are available. Having a second
VINto 5V converter would be great. - MicroSD slot : very useful when getting logs.
- Keep it hand solderable : as much as possible, avoid really small components (like
0402).
Honorable mention :
- Ethernet : Sadly not possible. One signal on the LQFP48 package is missing for full Ethernet. It is the
RMII_RXD1. :( Sticking an RJ45 port on a blue pill seems a bit unrealistic. Plus it requires an additional IC (an Ethernet PHY). So a dedicated PCB should be designed.
As explained previously, all the C5 in LQFP48 package are pin compatible!
- The cheapest : STM32C531CB (but without FDCAN)
- Middle ground : STM32C552CE or with AES STM32C562CE
- Biggest memory : STM32C5A3CG
The PCB design will be compatible with any of them, but features may not. So the board should be populated accordingly.
The package choices are made that are deemed "not too painful to solder" but still compact. If you can solder a LQFP package, chances are you can solder 0402. 0805 is too big. 0603 is a good compromise. QFN packages may get tricky to solder.
The bluepill gets itself into all kinds of projects. It is a limiting factor to be forced to provide 3.3V to 5V. Would it be great if it could be powered, let's say by the same 12V supply that powers your LED strip? Or the 2S LiPo battery of an RC device?
Using an LDO in a tiny package to convert higher voltages to 5V is not a good idea. The power dissipation is the voltage drop times the current. So, for 12V - 5V = 7V, let's take 350mA, it would be 2.45W. Toasty. Instead, a buck converter is better since it's much more efficient. However, this requires a "power" inductor, not the simple SMD 0603. Good characteristics are 4.7uH, <100mOhms, and a good margin over the current saturation. They are quite commonly found in a 4x4mm package. This can be a bit bulky. If this inductor is populated on the bottom side, it should be lower than the plastic bit of the header pins. More on that later.
The plan is to have a VIN to 5V, and then a 5V to 3.3V. A selection between the buck 5V or the USB 5V could be done through a 3-pin header of an SMD switch if the PCB is too crowded. If the buck converter is not populated, the board can still be powered by 5V sources through the header pins.
To avoid sacrificing a header pin for the VIN and taking the risk of injecting "high" voltage (>5V) on a shield board, a dedicated header should be used. Since the SWD interface on the original blueprint has only 4 pins, there is space for a 5th one. The only risk would be that the user puts the VIN voltage on any other pin. That would fry the board.
It will be important to route this part properly to avoid EMI. When a transient current has to travel through a large loop, that loop behaves like an antenna. Plus, sensitive data lines and clocks should be routed away from power elements.
Important: See the Summarizing power budget section as it may impact the choice of the LDO
USB-C is compatible with USB 2.0 and HS or FS (even though we have only FS). All the data is going through D+/D- pins, just like micro USB. To be able to behave as a host, the board must deliver a VBUS. It is not planned on a "bluepill" oriented board. Plus, it would require an additional chip to negotiate the host/device roles. Thus, the board will be device only. CC1 and CC2 will be connected to resistors to signify that. For now, it is in 99% cases good enough.
An ESD (TVS) protection is needed to absorb any high voltage spikes due to electrostatics on D+/D- lines. A good option is the ST USBLC6-2SC6.
A diode (Schottky) is put on the USB VBUS to avoid the "back-power". If the board is powered by another device while plugged into a USB port through a cable, this prevents damage. A SOD123 package, 1A 40V is plenty enough.
On the C5 (like on the STM32F103), there is an LSE and an HSE. On the STM32F103, and on many other MCUs, the reasons to use each type of oscillator are the following :
-
LSEandHSE- Cheap
- Precise (10th of ppm)
- Both are required since the internal
HSIandLSIcan have a high ppm. Thus, some applications, like the USB, cannot run
-
LSE- Requires less power to drive the oscillation. Thus used for low-power applications and can keep a clock during standby and/or stop modes.
- 32.768kHz is 2 to the power of 15, making it perfect for counting 1 second.
-
HSE- On the
STM32F103,LSEcannot be used as the system clock or as a source for thePLL. Thus, to have a precise system clock, it was required to use theHSE. - Using a higher frequency oscillator reduces the jitter multiplication (if
PLLis used). Thus more suitable for applications like audio.
- On the
What changes with the C5 :
LSEcan now be used by thePSI(which behaves as aPLL)- The MCUs are equipped with the
CRS(Clock recovery system). This system takes inHSE,LSE,USB SOF, or an external reference clock to trim on the fly theHSI.
Different scenarios requiring a precise clock :
| Scenarios | HSE |
LSE |
CRS |
PSI (PLL) as sys clock |
|---|---|---|---|---|
| Only using USB | Not required | Not required | USB SOF | Not required |
| Using RTC | Not required | Yes | Not required | Can be used |
| Using low power | Not required | Yes | Not required | Can be used |
| Jitter sensitive | Yes | Not required | Yes | Can be used |
Based on that, and to keep compatibility with the bluepill, both footprints for HSE and LSE exist. By default, the PC14/PC15 are available on the header. It is possible to change the configuration to have PH0/PH1 on the header instead. Also, to reduce costs, it is conceivable to not use any external oscillator at all and rely on the CRS for specific cases.
On the STM32F103, it was possible to boot in :
BOOT0 |
BOOT1 |
What boots | Address |
|---|---|---|---|
| x | 0 | User flash | 0x0800 0000 |
| 0 | 1 | System memory | bootloader address |
| 1 | 1 | RAM | 0x2000 0000, aliased : 0x0000 0000 |
On the C5 family :
BOOT0 |
What boots | Address |
|---|---|---|
| 0 | BOOTADD[31:8] |
default : 0x0800 0000 |
| 1 | System memory |
bootloader address |
On the C5 family, the boot in RAM is no longer available. So we either need the bootloader to flash our code through peripherals (more on that in another section), or the user flash. To avoid using pliers to short a solder bridge, the button is still the superior design, but not required.
Note: If the option bit
BOOT_SELis set to 0, the BOOT0 pin is not sampled anymore. Also, if the flash memory interface detects that the content atBOOTADDis not programmed, the chip will automatically jump to the bootloader. Can be useful if mass programming boards.
Note that the BOOT0 can be used as a GPIO, see below. But it should not be the default behaviour.
On the STM32F103, the PB11 is on pin 22. On the C5 family, it is VCAP. So the new board does not expose the pin 22 to avoid any burnout. However, some shields may use the PB11. A choice can be made to set the BOOT0 pin as a GPIO through user options in CUBE programmer. If this choice is made, BOOT0 is no longer available, so flashing the board can only be performed through SWD interface. With a simple firmware redirection of PB11 to PH2, the functionality can be preserved. However, the peripherals available are not the same: MCO1, LPTIM1.IN2, TIM17.CH1N (not on C53x/C54x version), FDCAN1.RX. Compared to the STM32F103: TIM4.CH4, I2C2.SDA, USART3.RX.
Some makers may be eager to try out the C5 bluepill with an F103 while waiting for stocks to fill up. So, another solder bridge maps the ex-PB11 header to pin 22. Be careful while swapping back to a C5.
The decision is to put a solder bridge:
- Default (safest):
ex-PB11unconnected BOOT0asPH2(advanced option):ex-PB11connected to pin 44STM32F103compatible (shield compatibility):ex-PB11connected to pin 22, keepingPB11
Another pinout difference is that in place of VBAT, the C5 family has PE2. It does not hurt to have another GPIO on the header. However, if some specific shield boards power the bluepill through VBAT, it should be kept as is. VBAT is basically VDD on the C5. So there is a solder bridge that can be cut to unconnect the VBAT header pin from VDD, and connect the PE2 instead.
For big fingers, the buttons should not be too small. A good option is a 3x6x2.5mm. No need for 4 legs.
It is more comfortable to have a hardware debounce instead of a small piece of code.
- Reset button
- User button is useful.
PC13is interesting for triggering wakeup BOOT0button can still be useful to flash code through DFU mode over USB. There is the possibility to configure it as thePH2and have an extra user button.
The C5 family on the 48-pin packages has the VDDA and VSSA pins replaced by VREF+/VREF-. According to the power supply scheme, it seems that the VREF- is not used and tied to GND. On C5, VDD and VDDA are common within the chip.
Only a 100nF is required between the VREF+ and VREF-, according to the documentation. And the VREF- is tied to GND.
On most F103 designs, this is how the VDDA/VSSA are wired anyway. Just make sure that it is the case before trying a chip swap.
Moving the SWD 4-pin header closer to the edge of the board gives more room for the components. The advantage of having a horizontal header is not clear. Perhaps the cable management is more pleasant in that way. So, to give some room for the components, it was moved closer to the edge.
As mentioned before, a 5th pin was added for the VIN.
If the STM32C59x/STM32C5Ax are chosen, they have Octo-SPI, which can really be used only as Quad-SPI on a LQFP48 package. Depending on the need, a QSPI NOR or QSPI PSRAM can be populated. They can be pin compatible. For example :
QSPI NOR:MX25Rfamily fromTIQSPI PSRAM:AP Memory APS6404L-3SQR-SNas 64 Mbit
These options can be really useful for logs, assets (images), firmware storage, and buffers.
Quickly reading logs or importing files to the STM32 is a great feature. It is not possible to use the QSPI on an SD card as the controller has a special protocol that micro SD cards may not support. So, the micro SD uses simple SPI protocol. Any of the 3 main C5 variants can use it.
ESD protection should be considered.
A very simple way to measure current is to place a low-value shunt resistor in the low-side return path, connect its upper node to PB0, and configure the internal OPAMP as a non-inverting PGA. The load current generates a small voltage across the shunt equal to Vshunt = I × Rshunt, and the OPAMP amplifies this ground-referenced signal so it can be measured accurately by the ADC. Since the shunt is placed on the low side, the input remains close to ground, which makes the measurement simple and practical.
This configuration makes sense on the C53x and C52x.
Special care should be taken when working with > 3.3V voltages. As wrong wiring could fry the blueprint entirely.
The CAN and CAN FD are widely used in automotive, industrial automation, and robotics because they provide robust differential communication over longer cables in electrically noisy environments. They also support multi-node networks for any kind of device. The bluepill could be a perfect tool to inspect, interact, or simply be used in such a network.
A transceiver is required for it to work. Instead of using jumper cables on header pins, why not directly embed a footprint on the board? A good candidate is PB8/PB9 since PA11/PA12 is already used for the USB. This is, of course, optional, so solder bridges are available to choose between either PB8/PB9 or the CANL/CANH of the transceiver.
A good option powered by 3.3V is the TCAN334 and its variants. The SHDN pin of the TCAN3414 that puts the device in ultra-low power shutdown mode is not really that relevant for a generic devboard. However, the standby mode could still be interesting. It is linked by a solder bridge to the PE2, since this pin does not have a lot of Alternate Functions and in a the configuration where VBAT header pin is connected to 3.3V, it is not used at all.
The issue with the TCAN3xxx is that they are not that available. It is possible to choose another FDCAN component since they are almost all pin compatible. So if the TCAN3xxx is not available, choose a 5V version that has better stocks. However, this would require powering the board with at least 5V. And changing the solder bridge.
Note, only C5 versions with FDCAN would work, like C5x2 or C5x3.
The idea is to populate one side with essential components, so that the process of reflow soldering is simpler. The top face will contain the MCU, oscillators, the USB connector, and the buttons. Any optional component will be populated on the bottom side and may require hand soldering. For example, the bulk, the CANFD, and all the solder bridges. Normally, the bluepill is intended to be put on a breadboard. So the header pin should point from the bottom side. From the moment that the components are not higher than the plastic of the header pins, then there is no issue putting them on the bottom side.
Fitting everything on a 2-layer PCB is a challenge that must be accomplished to reduce costs. Respecting the correct place and route to reduce EMI will be another challenge. An interesting compromise would be to place smaller components on the top side that could be assembled during manufacturing, leaving the bottom hand solder-friendly.
Any component should be low enough to fit under the plastic part of the header pin, so that the board can be fitted on a breadboard. If mounted somewhere else, take great care not to damage parts either physically, or electrically. The biggest setback for now is the power inductor.
Personally, I solder most of the time the header pins pointing away from the top face. As it is easier to secure the bluepill on an object and still be able to use the reset button. I also try to zip tie the board somehow to a support, often resulting in something unstable.
Putting one or two mounting holes in the middle of the board would be great in combination with a spacer to fix it on something sturdy. However, due to the limited space on the board, it's not really possible...
Since a lot of makers are equipped with a 3D printer, using a 3D printed adapter/casing would be the best solution.
A hybrid solution would be to have notches on the 4 sides of the board. One could use 4 x M3 bolts or a 3D printed case.
Comming soon (3D casing)
A user LED is a perfect feedback of the code's behaviour. The PA10 is the least alternate function-rich pin left.
Now that all the components have been more or less identified, it is a good time to sum up the consumptions.
Important Power figures are taken with a bit of margin and may not reflect the exact reality. It's important to have some headroom.
| Part | Consumption | Comment |
|---|---|---|
| C5s | 35mA | Taken from the C5Axx datasheet at Tj=30 with all peripherals enabled |
| LEDs | 30mA | Can be reduced |
| Bulk and LDO | <1mA | |
| FD CAN | 15mA | For the cheaper alternative |
| QSPI memory | 10mA | PSRAM consums more than NOR |
| SD CARD | 250mA | Largest power consummer. Can get worse. |
| Total | ~350mA | For a "round" number for the ON BOARD ICs |
Some conservative values that can be aimed for powering external boards or sensors.
- 3.3V : 100mA
- 5V : 150-250mA
- The buck can handle larger currents, so 250mA is very safe
- USB however, expects 100mA consumption by default and can go up to 500mA if the host can deliver it. It needs configuration during the first USB enumeration ("handshake"). So 150mA should be safe.
As a conclusion, the LDO can still be a cheaper version, but the user should be careful while operating the SD CARD.
Based on the design choices, the features can be categorised as follows:
- CORE : Present on all configurations: Decoupling capacitors, LDO, USB-C, headers, User LED, buttons.
- OSC : LSE and HSE
- BUCK : Vin to 5V
- FDCAN
- SHUNT : Current measurement
- MICRO SD
- EXT MEM : Choice between PSRAM or NOR
Based on all the features, here are some reasonable configurations. (X = present)
| Config | Comment | C5 | OSC | BUCK | FDCAN | SHUNT | MICROSD | EXT MEM |
|---|---|---|---|---|---|---|---|---|
| A | Cheapest viable solution | C531CB | ||||||
| B | Complete analog tool | C532CC | X | X | X | X | ||
| C | Middle ground | C552CE | X | X | X | X | X | |
| D | Large storage capacity | C593CG | X | X | X | X | X | |
| E | Extended storage capacity | C5A3CG | X | X | X | X | X | x |
Go play around with the Configurations table in hw/pcb/STM32C5_bluepill/STM32C5_bluepill_cost_estimate.xlsx. See below the BOM and Expected pricing.
The current state of the design is that the schematic is "done" in the sense that it follows the above explanations, except obviously mistakes. The PCB state has the parts placed but not routed at all, not talking about the silkscreen. This means that schematic and BOM are susceptible to change.
I'm using Kicad 9.0. This is important since some relative paths within Kicad are version-specific, like KICAD9_3DMODEL_DIR. Normally, every part should be available with the default installation. Except for some that can be found in the hw/pcb/libs/ folder.
Credit
I used a design for the buttons (TS09-63-25-R-260-SMT-TR) taken from SnapEDA. They remain licensed under CC BY-SA 4.0 with SnapMagic Design Exception 1.0.
Hardware revisions use the following format:
RevA vX.Y.Z - PW
RevA,RevB,RevC, ... = almost new board designs or major design generationsX= major changeY= feature addition or non-breaking improvementZ= bug fixW= design sent to manufacturing for theWtime
So a manufactured board may be identified as: RevA v1.2.3 - P2
Tag versions can be : RevA-v1.2.3-P2
Coming soon
This is a sneek pick ;) (Or just go see the files :D)
The headers are duplicated just to emulate different configurations.
Front
Back
This is a description of the features used on the board. For a full pinout "MBed" style (R.I.P), there would be a big list of Alternate functions to display on one image.
TOP
SWD / POWER HEADER (J6)
┌─────────────────────────┐
│ 5 : 3V3 │
│ 4 : SWDIO │
│ 3 : SWCLK │
│ 2 : GND │
│ 1 : VIN │
└─────────────────────────┘
LEFT HEADER (J3) RIGHT HEADER (J4)
┌───────────────────────────────┐ ┌───────────────────────────────┐
│ 1 - PB12 │ │ 1 - GND │
│ 2 - PB13 │ │ 2 - GND │
│ 3 - PB14 / SD_DETECT │ │ 3 - 3V3 │
│ 4 - PB15 / QSPI_IO0 │ │ 4 - NRST │
│ 5 - PA8 │ │ 5 - PB11 position / spare │
│ 6 - PA9 │ │ 6 - PB10 / QSPI_CS │
│ 7 - PA10 / LED │ │ 7 - PB1 │
│ 8 - PA11 / USB_D- │ │ 8 - PB0 / SHUNT │
│ 9 - PA12 / USB_D+ │ │ 9 - PA7 / QSPI_IO2 │
│ 10 - PA13 / SWDIO │ │ 10 - PA6 / QSPI_IO3 │
│ 11 - PB3 / SD_CLK │ │ 11 - PA5 / QSPI_IO1 │
│ 12 - PB4 / SD_DAT0 │ │ 12 - PA4 │
│ 13 - PB5 / SD_CMD │ │ 13 - PA3 / QSPI_CLK │
│ 14 - PB6 │ │ 14 - PA2 │
│ 15 - PB7 │ │ 15 - PA1 │
│ 16 - PB8 / CAN_RX / CANL │ │ 16 - PA0 │
│ 17 - PB9 / CAN_TX / CANH │ │ 17 - PC15 / PH1 selectable │
│ 18 - 5V │ │ 18 - PC14 / PH0 selectable │
│ 19 - GND │ │ 19 - PC13 / USER BTN │
│ 20 - 3V3 │ │ 20 - VBAT position / PE2 sel. │
└───────────────────────────────┘ └───────────────────────────────┘
BOTTOM
USB-C
Coming soon (For each IC, a list of compatible chips)
With the help of AI, I was able to produce some "guesstimation" of the different configurations. The prices are grouped by volume : Low (<10 boards), Medium (<1000 boards), Hgih (<10000 boards). The difference between medium and high is slim.
The prices are extracted on the 15th March in USD from various sites (Mouser, ST, LCSC, JLCPCB, alldatasheetde etc.). They are not taking VAT into account. Take this with a grain of salt, but at least it gives a rough idea.
Manufacturing costs are based on the modalities and capabilities of JLCPCB and PCBWay. Once again, for large volumes, this may be irrelevant. An estimation would be 0.60$, 0.08$, 0.04$ per PCB for different volumes.
The same goes for the assembly costs. But it depends on the number of components and how often a reel of components must be changed in the machine. Through-hole components are more expensive to assemble.
| Config | Low BOM | Low total | Med BOM | Med total | High BOM | High total |
|---|---|---|---|---|---|---|
| A | $4.30 | $8.46 | $2.19 | $3.24 | $1.86 | $2.75 |
| B | $6.23 | $10.46 | $3.18 | $4.30 | $2.74 | $3.69 |
| C | $6.93 | $11.20 | $3.57 | $4.74 | $3.06 | $4.04 |
| D | $7.82 | $12.09 | $4.06 | $5.23 | $3.40 | $4.38 |
| E | $9.76 | $14.05 | $5.63 | $6.81 | $5.08 | $6.07 |
Not bad, considering some bluepills with STM32F103 clones can be found in the ballpark of $1.91. Or the WeAct Studio design of the Bluepill+ that can be found at $3.45 with a genuine STM32.
The design can be refined and the BOM optimized.
Go play around with the Configurations table in hw/pcb/STM32C5_bluepill/STM32C5_bluepill_cost_estimate.xlsx. Add features and see price impact.
- bluepill mini - with LQFP32 or 20pin package
- bluepill eth - with RMII and T1S ethernet (Would require RMII_RXD1)
- STLINK-based C5
If you start exploring one of those, feel free to include me in the discussion. Or any other C5-based project. I'm curious :)
For now, the stocks are still filling up. All the C5 mentioned above are not all yet available. If there is demand, I may be willing to consider perhaps in some conditions with big ifs one day getting a big batch produced for resale :). The price will not be dirt cheap since I plan on not losing money, but my goal is not to become rich from this project as well :D I will need help and advice in that case. Please let me know if you are interested.
Comming soon a form to contact.