IllustrationHardware/software integration is the work of making firmware, drivers, apps and cloud code run correctly on a new board. It starts with board bring-up, adds the board support package and drivers, fixes interface contracts such as BLE GATT tables and APIs, and tests the whole device at every gate for power, RF and timing problems.
A device project often runs into trouble where the board meets the code. The schematic can look right and the firmware can compile, and the first units still reset when the radio transmits, or the phone app receives half of every packet. This guide is for a product manager or engineering lead who needs to plan that work: what to bring up first, what the driver layer owns, how to write interface contracts, and which tests belong at which gate.
What does hardware/software integration cover in a device project?
In a connected device, integration means four layers that each need an owner on both sides. The hardware team owns the physical facts. The software team owns the code that depends on them. Each layer should leave a shared artifact that both teams edit and that a reviewer can check.
| Layer | Hardware side | Software side | Shared artifact |
|---|---|---|---|
| Board bring-up | Rails, reset circuit, clocks, strapping resistors, test points. | First boot image, console output, a script that reads every rail and ID. | A bring-up log with each check marked pass or fail. |
| BSP and drivers | Pin map, bus choices (I2C, SPI, I2S, UART), interrupt lines, power domains. | Device tree or pin configuration, drivers, sleep and wake hooks. | One pin and peripheral table that both sides edit, under version control. |
| Interface contracts | Which radio, which antenna, how much power each mode can spend. | GATT table, message formats, API versions, update protocol. | A written contract with version numbers and test vectors. |
| System behavior | Battery, thermal limits, RF performance in the enclosure. | Scheduling, retries, buffering, error states the user sees. | Integration test plan with pass lines, run at every gate. |
How do you bring up a new board?
Bring-up is the first contact between new hardware and code. Work from the bottom up: power, reset, clocks, boot, then one peripheral at a time. Load the full application only after the basics pass, so a failure points to one part.
Power, reset and boot first
The chip vendor's schematic checklist tells you what to check. The rows below come from the Espressif ESP32-S3 schematic checklist, as of November 2026. They apply to that chip only. Other chips have their own numbers, so use your vendor's document the same way.
| Check | What the checklist says | How to verify on the board | Source |
|---|---|---|---|
| Supply | With a single power supply, 3.3 V with output current of no less than 500 mA is recommended. Add at least 10 µF and an ESD diode at the power entrance. | Measure the rail during a radio transmit burst, not only at idle. | Espressif schematic checklist, as of November 2026 |
| VDD3P3 decoupling | A 10 µF capacitor on the VDD3P3 rail is highly recommended, because current draw can jump while the chip transmits and collapse the rail. | Check that the part is fitted and close to the pins on the real layout. | Espressif schematic checklist, as of November 2026 |
| Reset timing | CHIP_PU should go high only after the 3.3 V rails are up. tSTBL and tRST are each at least 50 µs. The usual RC is 10 kΩ and 1 µF. | Scope CHIP_PU against the rail on a cold power-up and on a fast off-on cycle. | Espressif schematic checklist, as of November 2026 |
| Battery or slow supply | With slow power rise or fall (such as during battery charging), frequent power on-off or an unstable supply, an RC circuit alone may not meet the timing. Reserve a power monitor chip with a threshold of about 3.0 V. | Repeat the reset test while the charger is connected and while the cell is nearly empty. | Espressif schematic checklist, as of November 2026 |
| Boot mode | GPIO0 and GPIO46 select the boot mode. Their levels must hold for at least 3 ms after CHIP_PU goes high while the chip reads them. A high-value capacitor on GPIO0 may put the chip into download mode. | Power-cycle many times and count any boots into download mode. | Espressif schematic checklist, as of November 2026 |
| RF path | RF traces need 50 Ω impedance control, and the matching network sits close to the chip. With RF enabled, an antenna must be connected. | Never run radio firmware on a board with the antenna or match left unfitted. | Espressif schematic checklist, as of November 2026 |
Keep a bring-up log
Record each check, the measured value and the board serial number in one log, and run the same script on every new board. A board is ready for firmware work only when every line passes.
What goes into the BSP and driver layer?
The board support package (BSP) tells the software what the board is. It holds the pin map, the clock setup, the bus assignments and the power domains. Drivers sit on top and talk to each part: sensors, codec, display, charger, radio.
Three rules keep this layer under control:
- One source of truth for pins. Hardware and firmware edit the same table, and the BSP is generated from it or checked against it.
- Every driver has a sleep and wake path. Sleep current is a driver problem as often as a hardware problem.
- Every driver has a stand-alone test: probe the part, read its ID, run one transfer, put it to sleep. Run it on each new board revision.
Version the BSP with the board revision, so a firmware build knows which board it was made for. For more on how firmware is delivered and owned, see our firmware engineering page.
How do you write interface contracts for BLE GATT and APIs?
An interface contract is a short document that says exactly what crosses a boundary: device to phone, device to cloud, firmware to update server. Each side builds and tests against it.
The BLE GATT table
Over Bluetooth LE, the contract is the GATT table. The TI BLE5-Stack user guide, as of November 2026, describes the parts you need to pin down (TI GATT guide):
- A service is a collection of characteristics. UUIDs are 2 bytes or 16 bytes, and some are Bluetooth SIG-defined while others are custom.
- Each characteristic declares its properties: read, write, write without response, notify or indicate. Notifications are sent without acknowledgment. Indications are acknowledged.
- The Client Characteristic Configuration descriptor (UUID 0x2902) turns notifications or indications on and off.
- The default ATT_MTU is 23 bytes. Notifications longer than 20 bytes (ATT_MTU minus 3) are truncated on devices that do not support a larger MTU.
- Only the client can start the MTU exchange. The result is the smaller of the two MTU values, and the exchange is repeated on each connection.
Put each of these in the contract, along with byte order, units, a version characteristic and sample payloads as test vectors.
Connection parameters
The Espressif ESP-IDF guide, as of November 2026, gives the connection interval range as 7.5 ms to 4.0 s in 1.25 ms steps. The central sets the first value in the connection request, and it can be changed later (ESP-IDF connection guide). A longer interval lets the device sleep more. A shorter one moves data sooner. Test the values on the phones your users carry and write the accepted range into the contract.
Cloud APIs and the update path
For the cloud side, the contract lists endpoints, message formats, auth, error codes and API versions. The firmware update path deserves its own section. NIST IR 8259A (May 2020) lists Software Update in its device cybersecurity core baseline. Its elements include verifying and authenticating any update before installing it, letting authorized entities roll back to a previous version, and restricting updates to authorized entities (NIST IR 8259A, as of November 2026). Use them as a checklist for the update contract.
How does hardware software co-design prevent late surprises?
Co-design means the firmware and app leads join the chip, power and layout decisions before the board is drawn. The surprises below tend to appear late because each one sits between two teams. The right column shows the early step that catches it.
| Late surprise | How it shows up | Co-design step that catches it |
|---|---|---|
| Power: supply sag under transmit | Random resets or audio dropouts when the radio sends, often only on a weak battery. | Budget peak current with the firmware team before the regulator is chosen, then test the reset circuit at low charge. |
| Power: sleep current higher than planned | Battery life falls short, and the cause is a pull-up, a floating pin or a peripheral left on. | Give each driver a sleep hook from day one and measure board sleep current after every driver change. |
| RF: radio works on the bench, fails in the enclosure | Range drops once the board is inside the case or on a wrist. | Plan the antenna area and the match with the mechanical team, and tune with the enclosure on. |
| Timing: BLE data arrives late or cut short | Notifications are truncated, or the app sees long gaps between packets. | Write MTU and connection interval into the GATT contract and test against the real phone app. |
| Timing: boot or wake races | A sensor is read before it is powered, or a strapping pin is held by another circuit at reset. | Write the power-up order into the BSP and check it with a scope on the first boards. |
RF changes late in a project also touch certification. Under 47 CFR 2.803(b), no person may market a radio frequency device unless it is authorized (47 CFR 2.803, as of November 2026). The same section lists narrow exceptions, such as conditional sales with set disclosures. If a late antenna or layout fix moves the certification date, the launch date moves with it. This is an engineering note. Ask counsel before you rely on it.
What should the integration test plan check at each gate?
The rows below follow the gates on our gated prototype development process. Each gate adds tests, and earlier tests keep running.
| Gate | Integration checks |
|---|---|
| Gate 0: Feasibility | Pick chips and modules with the software stack in mind. List each interface the device will expose, the power modes it needs, and the integration risks to retire first. |
| Gate 1: Works-like prototype | First firmware runs on the target silicon. Measure power, latency and RF on the prototype. Freeze a first draft of the GATT table and the cloud API. |
| Gate 2: EVT · first custom PCB | Full board bring-up on the custom PCB. Every driver passes its own test. The contract tests run against the real app and backend. OTA and provisioning work end to end. |
| Gate 3: DVT / PVT · small batch | Run the complete test plan on units built in the target process. Retest RF in the final enclosure. Lock firmware and contract versions for the units that go to certification and users. |
| Gate 4: Mass production | Production test checks each unit: rails, radio, sensors, firmware version and device identity. Any firmware change reruns the regression suite before release. |
Give every test a written pass line before you run it, and record the board revision, firmware version and contract version with each result. For what each gate delivers and how to exit, read EVT, DVT and PVT explained.
What should you ask your hardware team?
Take these questions to your own team or to any outside team before the first board is ordered.
- Is there one pin and peripheral table that firmware and hardware both edit, and where does it live?
- What peak current does the radio draw, and has the supply been tested at that load on a weak battery?
- Is the GATT table written down with UUIDs, properties, payload formats and a version number?
- What MTU and connection interval does the app expect, and on which phones were they tested?
- How is a firmware image verified before it installs, and how does a unit roll back?
- Which integration tests run at each gate, and what is the pass line for each one?
What is the difference between hardware/software integration and hardware software co-design?
Co-design is the planning side: both teams decide chips, pins, power and interfaces together before layout. Integration is the build-and-test side: bring-up, drivers and proof that firmware, app and cloud work on real units.
When should integration testing start?
Start at the first prototype that runs on the target silicon. Waiting for the custom PCB means power, RF and timing problems show up when they are most expensive to change. Our process page shows where each gate sits: gated prototype development.
Does the GATT table need a version number?
Yes. Phone apps and firmware ship on different schedules, so the app must know which table it is talking to. The TI BLE guide also notes that the MTU exchange must be repeated on each connection, as of November 2026 (TI BLE5-Stack GATT guide). Write both into the contract.
Can Duobay help with integration on my device?
Our Shenzhen engineering team covers electrical, firmware, app and test work, and by default we test the device and its SDK against your backend. We do not publish prices. Tell us about your device and we will explain how the gates would apply to it.
If you are planning a device and want the integration work scoped gate by gate, tell us about your device.
Where do these figures come from?
All pages accessed November 5, 2026. Re-read them before you rely on any figure.
- Espressif, ESP Hardware Design Guidelines, ESP32-S3 Schematic Checklist: https://docs.espressif.com/projects/esp-hardware-design-guidelines/en/latest/esp32s3/schematic-checklist.html (accessed 2026-11-05)
- Espressif, ESP-IDF Programming Guide, BLE Connection: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/ble/get-started/ble-connection.html (accessed 2026-11-05)
- Texas Instruments, BLE5-Stack User's Guide, GATT: https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/latest/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gatt.html (accessed 2026-11-05)
- NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline (May 2020): https://doi.org/10.6028/NIST.IR.8259A (accessed 2026-11-05)
- 47 CFR 2.803, Marketing of radio frequency devices prior to equipment authorization, eCFR: https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-2/subpart-I/section-2.803 (accessed 2026-11-05)
Planning a device like this? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →