BladeCore‑M54E is part of the BladeCore modular controller series.
Each BladeCore variant is implemented as a standalone hardware repository, sharing a common architectural philosophy while targeting different microcontrollers and interfaces.

This repository documents the BladeCore‑M54E hardware, which is based on the RP2354B microcontroller and integrates Ethernet connectivity.

The BladeCore series consists of the following hardware variants:

The BladeCore naming scheme encodes the microcontroller family and primary communication interface directly in the module name:

• M40 designates an RP2040‑based module
• M54 designates an RP2354B‑based module
• E suffix indicates integrated Ethernet support
• C suffix indicates integrated CAN support

Variants without a suffix represent the base module for that microcontroller family, without Ethernet or CAN integrated.

Each BladeCore variant is implemented as a separate hardware design and repository.

BladeCore‑M54E is a compact controller module built around the RP2354B microcontroller, combined with a W5500 Ethernet controller with integrated PHY.
The module is designed as a 2980‑size M.2 M‑Key card (29 mm wide, 80 mm long, non‑standard width), intended to be embedded into a carrier board or system that provides power through the M.2 edge connector.

The design integrates:

• RP2354B microcontroller
• External QSPI flash memory
• External I²C EEPROM
• 100BASE Ethernet via W5500
• Dual‑path USB connectivity with automatic source selection
• Onboard power regulation and defined power‑up sequencing

This repository contains the schematics and documentation.

• BladeCore‑M54 schematics (PDF).
• BladeCore‑M54 KiCad folder.

• KiCad Libraries: src/HardwareDesign/Libraries/KiCad
  • BladeCore‑M54E footprint
  • BladeCore‑M54E symbol
  • Plain M.2 connector footprint (MDT420E03001)
  • 3D STEP: BladeCore‑M54E + MDT420E03001 assembly
  • 3D STEP: M.2 connector
• Eagle Libraries: src/HardwareDesign/Libraries/Eagle
  • Status: Work in progress

Top view

Bottom view

• M.2 2980
• M‑Key
• Power and I/O routed through the M.2 edge connector

• RP2354B
• External 12 MHz crystal
• Internal 1.1 V core supply generated by the MCU
• SWD debug interface available
• GPIOs routed to the M.2 edge connector

• Integrated Flash
  • RP2354B
  • Capacity: 2 MB
• External QSPI Flash
  • W25Q128JVPIQ
  • Capacity: 16 MB
• External I²C EEPROM
  • AT24C256
  • Capacity: 256 kbit

• W5500 Ethernet Controller with integrated PHY
• Interface to MCU via SPI
• Supports 100BASE‑TX
• Dedicated reset and interrupt signals
• Link and activity LEDs implemented

BladeCore‑M54E supports two physical USB connection paths:

1. USB routed through the M.2 edge connector (external host or carrier board USB), and
2. Onboard USB‑C connector.

A FSUSB42 USB 2.0 high‑speed multiplexer is used to select which USB path is connected to the RP2354B.

USB path selection behavior:

• By default, the USB data lines are routed to the M.2 edge connector.
• When the onboard USB‑C connector is plugged in, the FSUSB42 automatically redirects the USB data path from the edge connector to the onboard USB‑C connector.
• Removing the onboard USB connection restores the default routing to the M.2 edge connector.

This allows the module to be normally operated via a carrier board USB connection, while still enabling direct access through the onboard USB‑C connector when needed, without manual configuration.

• Input supply: 5 V (M.2 pins 14/16 or VBUS) or 3.3 V (M.2 pins 10/12, LDO bypassed)
• TPS74801 low‑dropout regulator generating 3.3 V from 5 V input
• Regulated 3.3 V output to carrier board on M.2 pins 10/12 (up to 1 A, limited by connector)
• Power‑good signaling with visual feedback (LED via SN74LVC1G97 buffer)
• USB VBUS sensing routed to ADC
• Four power paths: M.2 5 V, M.2 VBUS, onboard USB‑C, or external 3.3 V

*SPI1 is used for the onboard Ethernet controller (W5500)

**I2C0 is used for the onboard EEPROM (AT24C256) on GPIO32/33, which are internal to the module and not routed to the M.2 connector. Carrier board I2C0 on other GPIO pairs is physically independent.

• This documentation intentionally avoids assumptions about firmware features, supported protocols, or software behavior.
• All statements are derived from the provided schematics and explicit design notes.
• Component‑level limits and behavior should be verified against the respective datasheets.

Hardware designs, schematics, and related documentation are licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0). See the Hardware License file for details.

• ✅ You can study, modify, and distribute the hardware designs

• ✅ You can create derivative works for personal, educational, or non-commercial use

• ✅ You can build this project for your own personal use

• ⚠️ You must give appropriate credit and indicate if changes were made

• ⚠️ You must share any modifications under the same license terms

• ⚠️ You must include the original license and copyright notices

• ❌ You cannot use the designs for commercial purposes without explicit permission

• ❌ You cannot manufacture and sell products based on these designs without a commercial license

• ❌ You cannot create closed-source derivatives for commercial purposes

• ❌ You cannot use the designer's trademarks without permission

Commercial use of this project is prohibited without obtaining a separate commercial license. If you are interested in:

• Manufacturing and selling products based on these designs
• Incorporating these designs into commercial products
• Any other commercial applications

Please contact me through any of the channels listed in the Contact section to discuss commercial licensing arrangements. Commercial licenses are available with reasonable terms to support ongoing development.

For questions or feedback:

• Email: dvidmakesthings@gmail.com
• GitHub: DvidMakesThings

Contributions are welcome! As this is an early-stage project, please reach out before making substantial changes:

1. Fork the repository
2. Create a feature branch (git checkout -b feature/concept)
3. Commit your changes (git commit -m 'Add concept')
4. Push to the branch (git push origin feature/concept)
5. Open a Pull Request with a detailed description