Mistake on this page?
Report an issue in GitHub or email us

Prototype

Custom hardware design

Although using our extensive portfolio of development boards and components can vastly speed up your development process, when you reach the prototype stage you need to finalize your custom hardware design. It must include a supported MCU, an interface such as DAPLink or ST-Link, and connectivity options relevant to your application.

Use your proof of concept hardware as a starting point. Select the components from your development board and expansion shields and integrate them directly onto a printed circuit board (PCB) with a form-factor of your choice.

You may also make optimization and security focused hardware choices in this stage. For example, you might consider using SPI Flash instead of an SD card for increased physical security and form-factor aesthetics. Or you might add a True Random Number Generator (TRNG) for generating keys on the device itself.

Alternatively, our Hardware Development Kit helps hardware engineers design real form factor products, so you won't need to rely on generic development boards for mass production. It also discusses a number of optimizations to reduce complexity and cost, such as using a low-cost memory component rather than the SD card found on many development boards.

Porting custom hardware to Mbed OS

Mbed OS compilations are board-specific. In other words, each board has its own compilation target on Mbed OS. When you create a custom board, you therefore need to create (or port) a custom target as well. You can minimize your porting effort by selecting one of our supported development platforms.

We have an extensive guide to the Mbed OS porting process as part of the Mbed OS documentation.

Porting custom hardware for Device Management Client

After porting your target to Mbed OS, you may also need to port Device Management Client using the Platform Abstraction Layer (PAL), which we created specifically to make porting as easy as possible. You can minimize the work by using one of our reference MCUs.

In general, you need to implement several functions that tell the client which hardware capabilities you have and how to access them. For example, if you added a TRNG to your device, you would need to implement the pal_osRandomBuffer() function to use the TRNG to generate a secure Root of Trust.

A guide to porting with the Device Management Client PAL and a reference example is in our Pelion documentation.

Custom hardware design example

In the previous stage, we provided an example of a proof of concept device with the following requirements:

  • A development board that supports CANBus out of the box, for asset monitoring.
  • An expansion shield for a Wi-Fi connection to Device Management.
  • A BLE shield to commission the device onto the Wi-Fi network.

In the prototype stage, design these components for your custom hardware:

Include the NUCLEO-F429ZI standalone MCU in your design. That makes your porting very easy: add a custom target to the TARGET_STM32F429xI folder in Mbed OS, and modify the target.json file so that you can compile for the new target. The WIZnet WizFi310 Wi-Fi shield includes a Wi-Fi module that you can solder to your custom hardware. Mbed OS includes the needed drivers, so you won't need to port it; you only need some minor configuration changes, including the correct UART RX and TX pins, to account for the new hardware design. The X-NUCLEO-IDB05A1 BLE shield depends on the SPBTLE-RF0 Bluetooth chip, which you can integrate directly into your custom hardware PCB. Mbed OS already supports the drivers for this chip, so your original code needs only minor configuration changes.

Software considerations: a custom bootloader

As you move through the development process, you may find that you need to develop your own custom bootloader or optimize the existing reference bootloader.

You will need to carefully consider your system memory layout. You need to create the following components, and ensure that they can find and access each other:

  • A bootloader that can replace (write) the existing active device application with the new firmware candidate.
  • An active device application running Device Management Client or Client Lite, at a location known and accessible to the bootloader.
  • A storage area large enough to store at least one new firmware image.

If you are developing a custom bootloader, you need to port both the Update client and the bootloader itself. For more information, please see:

Important Information for this Arm website

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.