Bootloader and IAP protocol with Waijung blockset


This demo showing an example of implementation the run-time firmware upgrade, mostly used in the product that need features update, bugs fix at end user or located on network. Waijung Blockset provide blocks function to develop this features, demonstration here tested with STM32F4 Target. The demo files are available for commercial and academic licensed users only.


  • Operate in normal operation during receive upgrade ROM (new firmware), device required to reboot only when finish receiving ROM data.
  • Fail safe upgrade, continue to operation in current running software in case of upgrade fail or error. Boot loader able to retry the upgrade operation when power interrupt during erase or copy sector.
  • Firmware validation, reject the corrupted or invalid upgrade ROM.
  • Internal flash memory division into 4 sectors: Bootloader, User application, upgrade ROM and user data.

Flash memory organization (STM32F4, 1MB Flash)


  • Boot (128kB), this sector is program once by designer or product manufacture using standard programming tool (eg: ST-Link programmer), and cannot be upgraded during application running. This boot firmware is located on flash sector 1 to 4, total 128kB size (see product sheet of STM32F4 for more details of Flash memory). Optional, Read/ Write protection can be activated to prevent unexpected write or erase to this sector.
  • User application, main program sector. It is user application, manage the IAP (in application programming) protocol. Note: IAP can be disabled if this sector did not implementing the communication protocol for receive Boot ROM.
  • Upgrade ROM, this is temporary storage area. It store the new upgrade ROM received from IAP communication.

Flash sector memory re-mapping

  • Sector B (User application), Flash memory address starting from 0x08020000. This start address will be remap to offset 0x00000000, and end address of Sector is 0x0803FFFF will be remapped to offset 0x0003FFFF.
  • Sector C (Upgrade ROM), Flash memory address starting from 0x08060000. This start address will be remap to offset 0x00000000, and end address of Sector is 0x0809FFFF will be remapped to offset 0x0003FFFF.

Communication type

IAP communication is data channel for receiving the new upgrade ROM. Depending on implementation in main program (user application) running, it can be UART, CAN or other.

Entry point and Sector validation (Sector B and C)

Sector B and C can be be validated by CRC32 and firmware signature, by using binary converter software to embedded these value into binary for upgrade ROM

  • image06Entry point, located at start of sector. During MCU startup, entry point is 0x08000000 (Boot sector), boot firmware validate the CRC32 of sector C to perform upgrade if available, then validate sector B (User application) to jump for main program operation.
  • CRC32 validation
    • During startup, boot loader will calculate CRC32 of sector C and B from offset 0x00000000 to offset 0x0003FFFB. Then compare CRC32 from calculation value to embedded value.
    • During normal running, main program (user application) validate the CRC32 of sector C (Upgrade ROM) before reboot to operate in Boot sector.

CRC32 calculation

Polynomial: 0x4C11DB7
Initial value: 0xFFFFFFFF

Binary conversion tool

[sta,msg] = amg_iaptool_binconvert(‘source file’,’size’,’output file’)
Example, run command at Matlab Command Window:

Bootloader startup sequence



  • Step 1: at MCU startup and operate in Boot sector. Boot firmware perform sector CRC32 calculation and Signature (optional) of Sector C.
  • Step 2: Firmware upgrade check, by validate sector C. Boot firmware will compare CRC32 of sector C and its embedded CRC32 value. If sector C valid indicates the firmware upgrade required, the next process will be Step 3. If sector C is not valid, then next process will be Step 4.
  • Step 3: Firmware upgrade operation.
    • Erase sector B (User application).
    • Copy entire data of sector C, write into sector B.
    • Then erase sector C, so next time startup sector C will be invalid and upgrade is not activated, the process will flow from step 2 to step 4.
    • Reset
  • Step 4: Main program validation. In this step boot firmware validate sector B, by verify Stack address value, calculate sector CRC32 and compare to its embedded value. If sector B valid, MCU will jump to entry point of sector B.
    Fail safe: in case of failure during step 3 (Power interrupt), boot firmware will retry the operation at next start.

Bootloader Demo

Model file

this demonstration imModel file, this demonstration implementing the Bootloader firmware. This model file will be program into sector A (Boot sector).

Demo model file: stm32f4_boot_256k.mdl


When “Boot” block located in the model and after build model, Waijung will generate call to function SYSTEM_BOOTLOADER() at file main.c.



Program Bootloader to device

This firmware will be program once from Auto Compile and Download or manual program via ST-Link tool.

User application and IAP protocol demo

Model file

File: stm32f4_user_app.mdl, this demo model disable auto compile and download.
The protocol of communication can be customized, in this demo use CAN Bus (CCP slave) for download ROM to upgrade.


Build and compile model file

This model need only compile, auto download will be disabled. The track build process show as below picture:


Target Setup

  • Add define at Compiler Control string: -DVECT_TAB_OFFSET=0x20000
  • Select None for Programmer/ Debugger option.
  • Disable (unchecked) option Full Chip Erase
  • Enable Auto Compile and Download option (Auto download will not run due to programmer selected as None)



Configuration subsystem

Configure the CAN bus interface and memory used by CCP slave handler.


CCP Handler subsystem

Basic implementation for CCP slave. Only some command support in this demo.


CRO MTA Parser subsystem

Handle the memory transfer address.

  • Extension address 0, Device ID. This extension address is for upload the data at memory SLAVE_DEV_ID which defined in block “Volatile Data Array1”. The valid address for this storage is 0 to 0x0F.
  • Extension address 1, Read only memory. This extension address is for upload data at memory READ_DATA which defined in block “Volatile Data Array”. This memory can be use to store the measurement data, use block “Volatile Data Array Write” to update this memory.
  • Extension address 2, Read and Write memory. This extension address is for upload and download data at memory CONTROL which defined in block “Volatile Data Array2”. This memory can be used for store the control value from Host. Use block “Volatile Data Array Write” to update this memory and use block “Volatile Data Array Read” to read value from this memory.
  • Extension address 3, this is Boot ROM memory address. During IAP process, host sending ROM data to store into this memory address.

Command Processing subsystem

This subsystem enabled only after receive CCP connect command. List of command support implemented in this demo:


Program the bootloader and user application firmware

  • Build and Program boot firmware (via ST-Link)
  • Build (Auto compile and Download) model file stm32f4_boot_256k.mdl to the target for one time. The target is now running at boot firmware (without a valid user application).
  • Build user application, build model file stm32f4_user_app.mdl, the output binary file will be created in output directory “stm32f4_user_app_stm32f4\stm32f4_user_app.bin”.
  • Generate binary file with embedded CRC32 calculation. Run below command at Matlab command window.



The binary conversion tool will generate output file stm32f4_user_app_convert.bin with embedded CRC32 at the end of memory sector (256kB size).

  • Program the User application for first time
    After done programing the boot firmware in step 1, it is no IAP handle running due to no valid user program. To program user application at first time still need ST-Link. use this command line run for program user application for the first time.



IAP protocol demo

When the target run in User Application (programming done at previous step), then it is now able be handle the IAP protocol.


To program the Target board via IAP (CAN), Host PC need another STM32F4 or STM32F0 board with CAN interface to convert the UART command to CAN message, and also receive CAN message then convert to UART response back to Host PC. As shown below diagram.



CAN-Serial bridge

Build model file stm32f4_can_serial_bridge_binary.mdl to run as CAN-Serial Bridge device. The protocol is similar to below URL except the target board is STM32F4:

Note for USB Converter used for USB to serial conversion

If use “aMG_USBConverter-N” or “aMG_USBConnect” for serial conversion, time for IAP may be reduced by set Latency to 1ms. Follow this instruction:

CAN bus message used in IAP demo

  • Step 1: Host send serial command to enable CAN-Serial Bridge to receive ID type standard, and ID filter is 0xFF. See topic Filter setting command:
  • Step 2: Host transmit CAN message (via CAN-Serial bridge), command CONNECT:
    Host Tx : [CCP_CONNECT] [CTR] [x] [x] [x] [x] [x] [x]
    Slave Tx: [0xFF] [CODE] [CTR] [x] [x] [x] [x] [x]
    ; Where CODE=0 indicate success.
    ; CTR is command counter
  • Step 3: Host transmit, command CCP_GET_SEED for programming.
    Host Tx : [CCP_GET_SEED] [CTR] [0x40] [x] [x] [x] [x] [x]
    Slave Tx: [0xFF] [CODE] [CTR] [PROTECT] [Key1] [Key2] [Key3] [Key4]
    ; Where PROTECT is programming protection status.
    ; Key1, Key2, Key3 and Key4 is seed key use by unlock command.
  • Step 4: Host transmit, command CCP_UNLOCK for enable programming.
    Host Tx : [CCP_UNLOCK] [CTR] [0] [0] [Key1] [Key2] [Key3] [Key4]
    Slave Tx: [0xFF] [CODE] [CTR] [Privileged status] [x] [x] [x] [x]
    ; Where Key1, Key2, Key3 and Key4 is seed key from GET_SEED command.
  • Step 5: Host transmit, command CCP_SET_MTA to configure address of Upgrade ROM (Extension address = 3), address to configure = 0x00000000.
    Host Tx : [CCP_SET_MTA] [CTR] [MTA0] [3] [0] [0] [0] [0]
    Slave Tx: [0xFF] [CODE] [CTR] [x] [x] [x] [x] [x]
    ; Where MTA0 = 0
  • Step 6: Host transmit, command CCP_CLEAR_MEMORY to erase flash memory at the current configuration of MTA done by previous step. The memory size to erase is 256kB.
    Host Tx : [CCP_CLEAR_MEMORY] [CTR] [0x00] [0x04] [0x00] [0x00] [x] [x]
    Slave Tx: [FF] [CODE] [CTR] [x] [x] [x] [x] [x]
  • Step 7: Host transmit, command CCP_SET_MTA to configure address of Upgrade ROM (Extension address = 3), address to configure = 0x00000000.
    Host Tx : [CCP_SET_MTA] [CTR] [MTA0] [3] [0] [0] [0] [0]
    Slave Tx: [0xFF] [CODE] [CTR] [x] [x] [x] [x] [x]
    ; Where MTA0 = 0
    ; Extension address = 3 for upgrade ROM.
  • Step 8: Host transmit the boot ROM data, command CCP_PROGRAM and CCP_PROGRAM_6.
    Host Tx : [CCP_PROGRAM_6] [CTR] [D0] [D1] [D2] [D3] [D4] [D5]
    Slave Tx: [0xFF] [CODE] [CTR] [MTA0] [Add3] [Add2] [Add1] [Add0]
    ; Where Add3, Add2,Add1 and Add0 is post increment address.CCP_PROGRAM:
    Host Tx : [CCP_PROGRAM] [CTR] [SIZE] [D0] [D1] [D2] [D3] [D4]
    Slave Tx: [0xFF] [CODE] [CTR] [MTA0] [Add3] [Add2] [Add1] [Add0]
    ; Where SIZE = 1 to 5, number of bytes to program
    ; Add3, Add2,Add1 and Add0 is post increment address.
    Following diagram showing transmit sequence for upgrade ROM data.



  • Step 9: Host transmit, command CCP_DISCONNECT. Target MCU will reset to operate in boot firmware when receive this command from Host.
    Host Tx : [CCP_DISCONNECT] [CTR] [x] [x] [x] [x] [x] [x]
    Slave Tx: [0xFF] [CODE] [CTR] [x] [x] [x] [x] [x]

IAP testing (Via CAN-Serial Bridge)

Command line:

At Matlab command windows, run command as show in below picture.



Wait until IAP process to finish.