Copyright
Copyright © 2019 Nonavisiion Scientific. All rights reserved.
License
Use of the software source code and warranty disclaimers are identified in the Software Agreement associated herewith.
Introduction
Bootloader for MCU through LLAC-CAN interface.
Design
The original design comes from Singapore team with changes to meet our hardware:
- The boot_state storage, changed to EEPROM (address 0), instead of battery backup SRAM in STM32F4.
- Code address, size and its checksum, changed to ROM (0xFFF00), instead system memory in STM32F4.
After power-up, the bootloader reads flag in EEPROM (address #0), it tells bootloader jump into application or not. If it is JUMP_TO_APPLICATION, the bootloader will verify the integrity of application and jump into it if it is OK.
If flag is STAY_IN_BOOTLOADER or application is currupted, it will stay in bootloader.
Host can talk with bootloader through LLAC-CAN interface, the node address is determined by the hardware id (software ID is not used).
Host can read/write global LLAC registers and talk with the unique driver BootProgram which controls the process of firmware updating through 3 registers:
- Control register - A bit vector to control the entire process
- Bit 0 - Commit - Commit a tranfer
- Bit 1 - Jump - Jump to application
- Bit 2 - Initiate - Initiate a new firmware updating process
- Diagram count - Number of diagrams has been sent by host in last transfer
- Transfer size - 1024 (read only) - tells number of bytes for each commit
The updating process can be divided into following steps:
- Step 1: Read TransferSize to know the size of transfer buffer in MCU;
- Step 2: Write value 0 to ControlRegister, followed by writing value 4 to ControlRegister, to reset the BootProgram module for new firmware updating process;
- Step 3: Send a block of binary file in LLAC bulk message, actually, the block will be divided into a couple of 8-byte diagrams, after the entire block is transfered, write actual number of diagram sent to DiagramCount.
- Step 4: Write ControlRegister with value 5, to commit the last transfer, so MCU will write the data into flash ROM;
- Step 5: Repeat step 3 and 4 until all contexts of binary file are sent;
- Step 6: The last step is write ControlRegister with value 6, this will trigger some actions in MCU:
- Clear the flag in EEPROM (so jump into application directly in next reset)
- Reset
Memory Map
Bootloader (0x00000000 to 0x0000FFFF)
The bootloader itself.
Application (0x00010000 to 0x000FFEFF)
The application code.
Checksum (0x000FFF00 to 0x000FFFFF)
- CRC32 checksum (4-byte)
- Start address of App (4-byte)
- Size of App in DWORD (4-byte)
- Version + Signature (2x2-byte)
Add header to binary file
Before downloading, a 16-byte header should be added to the binary file, it contains CRC32 checksum, start address, size in DWORD, version+signature.
The CRC32 checksum should be sum of all application code, DO NOT INCLUDE HEADER BYTES themselves.
Updating firmware with pyLlacTest
Add file header to binary file
Run following script to add file header to binary file
from vertumnus import *
Board.makeup_binary(
'../../application/tcmb_dc/mdk/Objects/MIB_K64.bin/VECTOR_ROM', # Compiled output
'out.bin', # Generated binary file
0x10000, # Start address
0, # Version
0 # Signature
)
- Due to the security zone at 0x00000400, so when application is linked with start address shifted (like 0x10000), the binary output would become a folder, like “MIB_K64.bin”, inside the folder, file VECTOR_ROM is the binary file we need.
- Considering to be compatible with next version bootloader with OS support, it is better to use 0x20000 as the start address of application.
Download
Run following script to download firmware into board, Enjoy!
from vertumnus import *
updateFirmware(
'TCMB-DC', # Name of board to be updated
'../../application/tcmb_dc/mdk/Objects/out.bin' # Binary file with added header
)
Use ‘MIDB’, ‘SMCB’, or ‘TCMB-AC’ for other boards.@TOC