Emre Ceylan
The classic hardware-software co-design tragedy shows up on the bench when someone asks, “Wasn’t this pin ADC?” The sensor net looks correct on the schematic, firmware builds cleanly, yet the pin is muxed to UART TX, JTAG, or another alternate function — so the analog reading sits flat or looks random.
At Revan Engineering, when PCB design and software development are not tied to one project truth, this class of mistake costs weeks. The examples below come from real bring-up and field commissioning notes; no customer names or board brands.
What is the hardware-software co-design tragedy?
The hardware-software co-design tragedy describes workflows where hardware reality and software assumptions are never synchronized. MCU pins are multifunction: the same pad can be an ADC channel, SPI MOSI, or GPIO. Even if the schematic net is `AI_TEMP`, a wrong `SENSOR_ADC_CH3` mapping in firmware makes the measurement path behave like a digital output.
“Wasn’t this pin ADC?” is usually asked when the schematic page and the `board.h` / device-tree line are not reviewed side by side. Co-design aims to merge both under a single pin truth; otherwise the prototype looks fine until a BOM revision on the production board exposes the gap.
Problem context
On a sensor-rich industrial board, a 0–3.3 V analog input is expected for temperature. Hardware reuses a block from an older project; software ports the reference board header. On Rev B the sensor pin moves to another port because of layout constraints; the schematic is updated but the firmware commit slips one sprint.
On the bench, `adc_read()` returns stuck 4095 or noisy garbage. The scope shows the correct signal on the pin; the issue is mux and channel number. Hardware says “PA3 ADC1_IN3, it’s on the schematic”; software says “our driver uses PA4”. Meetings run for hours; the real cost is a delayed field shipment.
Similar breakpoints: temporary GPIO on a JTAG pin for debug, bootloader UART colliding with the RS-485 transceiver, and alternate-function choices left “temporary” but shipped in the production image.
Technical analysis
Pin mux and alternate-function tables: On STM32, ESP32, PIC, and similar families each pin has an AF matrix. When layout swaps pins, not only the netlist changes — the `ADC_CHANNEL_x` → port map changes too. A schematic label `ADC1_IN3` may not match `LL_ADC_CHANNEL_3` in firmware; channel index and port index get confused.
Missing single source of truth: If IDE pin-config output (`ioc`, `pinmux.csv`) does not live in the repo, hardware revisions never reach software. An Excel pin list goes stale; CI keeps building with the old header.
Analog vs digital init order: If the pin is initialized as GPIO output first, switching to ADC mode may fail silently or corrupt internal sample-and-hold. The answer to “Wasn’t this pin ADC?” is sometimes “yes, but you made it push-pull first”.
Front-end and measurement path: An op-amp output reaches the MCU through a series resistor and filter; calibration assumes a different reference. Even with correct mux, scale and Vref errors look like a “broken ADC”.
Test visibility: A factory jig validates digital loopback; the analog path is not measured in ICT. Wrong mux passes automation and returns from the field as a “dead sensor”.
Field scenarios
- HVAC control board: Temperature ADC shared with UART debug; sensor froze in field service mode
- Hydraulic pressure interface: Pin swap on Rev C; old firmware image read the wrong channel on 200 boards
- Food-process IoT node: Battery ADC on the same port as charge-status pin; measurement vanished in sleep mode
- Motor drive daughter card: Temporary GPIO assignment for EMI testing merged into the production branch
- Retrofit gateway: `board.h` copied from old docs; conflict with the customer pinout PDF
Solution approaches
In co-design the pin list updates the same day as schematic approval: port, alternate function, net name, ADC channel, pull-up needs, and test point live in one CSV or YAML. Firmware uses a generated header; manual `#define` copies are reduced.
Bring-up checklists add a “pin truth walkthrough”: hardware, software, and test engineers validate scope traces and `adc_read` logs on the same pin together. Pin diffs on revision become mandatory release-note lines.
In Revan’s process, PCB design revisions and software development sprints track the same ticket; a pin mux change is not approved for board spin without a firmware merge. Early prototypes version pin-configurator output at the repo root.
Gains
When the hardware-software co-design tragedy is closed with one pin truth, bring-up drops from days to hours, field returns from wrong ADC channels fall, and Rev B/C regressions become visible. Measurable targets: all analog channels within expected mV range on the first bench session, and production images passing automated diff checks against the pin CSV.
Industry observation / experience
Hardware saying “the net name is on the schematic” while software says “it worked in the header” is technical debt, not org politics. Pin swap takes minutes in layout; without firmware and test updates the cost multiplies. On shared JTAG/UART pins, a debug cable distorts ADC readings and misleads field technicians.
When “temporary” firmware hacks leak into production, customer documentation never matches real pinout. Co-design meetings should stay short: one table and a joint measurement beat long arguments.
Conclusion
The classic hardware-software co-design tragedy turns pin mux drift into “Wasn’t this pin ADC?” Merge schematic, pin-config output, and firmware headers in one source; enforce revision discipline and shared bring-up measurements to catch errors before the field. Lock board spin and firmware on the same release train to carry bench success into production reliability.
🔗 Get in touch with us:
Phone/WhatsApp: +41 76 212 8248
📧 E-Mail: info@revantechnology.ch
For detailed information about our services in electronics development & PCB design:
Revan Technology – Your partner for professional electronics and PCB development
