Bootloader

Overview

The ARDEP bootloader uses MCUBoot and a Firmware Loader for firmware updates. This enables application upgrades either via UDS over CAN or USB DFU.

The recommended upgrade mechanism is the on-board debugger using the west flash command or if needed using UDS over CAN.

Building the bootloader

The bootloader can be built using sysbuild together with a sample for flashing. To reset the board to a delivery state, use

west build -b ardep samples/led -p --sysbuild

to build the LED Sample and bootloader

If you want to build for a specific board version, change the -b argument accordingly:

west build -b ardep@1.0.0 samples/led -p --sysbuild

Flashing the bootloader

Important

Bootloader and firmware loader can ONLY be flashed via debugger:

  • v2.0.0 and later: Must use the on-board debugger (OBD) - this is the recommended and default method

  • v1.0.0: Must use an external debug probe (e.g. J-Link, ST-Link)

The firmware loader itself cannot be flashed via USB DFU or UDS DFU. Only application updates can use the firmware loader’s DFU capabilities.

The bootloader and firmware loader are flashed via the on-board debugger using the west flash command.

Just run:

west flash

This will flash the bootloader and firmware loader to the board.

Firmware Loader Mode

The firmware loader supports both USB DFU and UDS DFU update mechanisms for application updates. When you set the BOOT jumper, the bootloader enters the firmware loader, which provides both update methods.

Important

The firmware loader can only update applications, not the bootloader or firmware loader itself. To update the bootloader or firmware loader, you must use the on-board debugger (v2) or external probe (v1).

It is helpful to see the Bootloader console output on UART-A for this.

Entering Firmware Loader Mode

To enter the firmware loader mode, pull the PE4 pin (labeled BOOT) to a LOW state (by setting the jumper) while power-cycling or pushing the Reset button.

The firmware loader will be active and ready to accept application firmware updates via either USB DFU or UDS (CAN).

On UART-A you will see output indicating the bootloader has started the firmware loader.

Note

UART-A is the output that is forwarded by the on-board debugger (on v2 boards) or available via the UART-A pins.

Upgrading the Application Firmware

You can upgrade application firmware using either method:

Via On-board Debugger (v2)

  • Note that this method only works on ARDEP v2.0.0 and later boards with an on-board debugger.

  • Build the application firmware you want to flash (assuming it is in the build directory)

  • Set the BOOT jumper and reset the board

  • Perform the upgrade with west flash

  • Wait for the upgrade to complete

Via USB DFU:

  • Note that this method works on all ARDEP boards (v1 and v2), but the first option is generally better for v2+ boards

  • Build the application firmware you want to flash (assuming it is in the build directory)

  • Set the BOOT jumper and reset the board

  • Perform the upgrade with west flash (for v2+ boards, set the runner: west flash --runner ardep)

  • Wait for the upgrade to complete

Via UDS (CAN):

  • Use the UDS diagnostic services over CAN to request a programming session

  • The firmware loader will handle the application update process

  • See Firmware Loader for details

UDS and USB DFU Support via Firmware Loader

Note

All ARDEP boards (v1 and v2): The unified firmware loader is now the default boot logic for all board versions. You can build any application with sysbuild and it will automatically include the firmware loader with support for both UDS DFU and USB DFU.

Upgrading from older ARDEP versions: If your bootloader was built with an older ARDEP repository version that differentiated between board versions, you need to upgrade the bootloader using sysbuild (via OBD on v2 or external probe on v1) to get the unified firmware loader support.

For applications that require firmware updates over UDS (Unified Diagnostic Services) or USB DFU, a Firmware Loader is provided which can be built using sysbuild.

It is not recommended to build the firmware loader independently as the bootloader needs configuration options to handle the firmware loader correctly.

For demonstration purposes, build the UDS Sample using sysbuild (which contains a sysbuild.conf), which automatically builds the firmware loader:

west build -b ardep samples/uds -p --sysbuild

If you wish to build your own application using the firmware loader, it is included by default when using sysbuild.

Note

Flashing considerations:

  • Bootloader and firmware loader: Can ONLY be flashed via on-board debugger (v2) or external probe (v1)

  • Applications: Can be flashed via debugger OR via the firmware loader (USB DFU/UDS DFU)

See Flashing the bootloader for detailed instructions.

Important

When using the default UDS instance (CONFIG_UDS_DEFAULT_INSTANCE=y, enabled by default on ARDEP boards), the firmware loader switch is handled automatically on programming session requests unless disabled with CONFIG_UDS_DEFAULT_INSTANCE_DISABLE_SWITCH_TO_FIRMWARE_LOADER=y.

If you create a custom UDS instance or disable the automatic switch, you must call uds_switch_to_firmware_loader_with_programming_session() in your diagnostic session control action handler when a programming session is requested.

To flash an application with the UDS firmware loader, see ARDEP UDS Runner.

Sysbuild

With sysbuild, multiple applications (i.e. bootloader, main application and firmware loader) are built together using just one build command.

More information is available in the official Zephyr Sysbuild documentation.

Sysbuild basics

There are multiple things that differ from a normal west build:

First, there are multiple targets for using menuconfig, one for each “domain”:

# Main application menuconfig
west build -t menuconfig

# Bootloader menuconfig
west build -t mcuboot_menuconfig

# Firmware loader menuconfig
west build -t firmware_loader_menuconfig

# Sysbuild menuconfig
west build -t sysbuild_menuconfig

Second, you can switch between domains when debugging by specifying the domain:

# Debug main application
west debug

# Debug bootloader
west debug --domain mcuboot

# Debug firmware loader
west debug --domain firmware_loader

Finally, when flashing, you can either specify no domain, which flashes all domains in series or you can specify a domain to flash only that domain:

# Flash all domains (bootloader, firmware loader and main application)
west flash

# Flash only bootloader
west flash --domain mcuboot

# Flash only firmware loader
west flash --domain firmware_loader

# Flash only main application (when building sample/uds the sample-name would be uds)
west flash --domain <sample-name>

Important

Note that on ARDEP v1 boards, only the main application can be flashed using the ardep runner. This also means that the bootloader and firmware loader must be flashed using an external debug probe, see Flashing the bootloader.