MCU Firmware Upgrade and BootLoader Solution

1. Hardware Background

1. The hardware solution is as follows, with the external 485 serial port communicating with the panel MCU, and the 485 serial port serving as the transmission channel for firmware upgrades.

1. The MCU model is the Aterly AT32F415RCT6, with a ROM size of 256KB, and no external flash, so backup areas are not considered. Based on the current conditions:

1. The flashing must be done in the BOOT software

2. There must be a method to force entry into the BOOT software, even if the APP firmware is invalid

3. When the panel software is running in BOOT, the power board software must also run in BOOT

1. Currently, the upgrade is conducted through wired transmission via the serial port, so encryption, retransmission, and other mechanisms are not considered

2. FLASH Partitioning

• PARAM: Parameter storage area, storing production data, device ID, log information, etc.

• APP: Application program running area

• INFO: Upgrade flag storage area

• BOOT: Boot program running area

3. Flashing Interaction and Data Format

3.1 Interaction Process

3.1.1 Start Upgrade

The PC sends a start signal, and the device responds to the start upgrade signal

1. After the PC sends the start upgrade request, it waits for a response,

2. If the device receives the start upgrade request while running in the APP, it records the upgrade status and responds to the upgrade after entering the BOOT

3.1.2 Send Firmware Package

The PC sends the firmware package content until all is sent

1. The first byte of the firmware content is the serial number (0x00~0xFF), ensuring transmission stability

2. Data packet synchronous transmission, the host sends data packets, and sends the next packet only after receiving a response

3. The device’s response includes different responses for correct, error, and failure, and the host processes according to different responses

1. If the response is correct, continue to transmit the next packet

2. If the response is an error, retransmit the previous packet

3. If the response is a failure, consider the upgrade failed and display the result to the user

3.1.3 End Upgrade

The PC sends an end signal, and the device responds with the firmware package

1. When the device receives the end upgrade command, it performs size verification, signature verification, etc., and responds with the verification result

3.1.4 Exception Handling

1. The PC starts recording timeouts after sending all request commands. If there is no response after a timeout, it retransmits. If retransmission exceeds a certain number of times without response, it is considered a burning failure

3.2 Interaction Data Format

• Unified data format

devID

cmdID

content

verify

• Verification algorithm

• The verification uses the CRC8 algorithm, with the polynomial x8+x2+x+1, and the initial value is 0x00

• Partial type definitions

typedef enum
{
    START_REQ = 0x11,//Start Upgrade
    PACK_REQ = 0x12, //Upgrade Package
    FINSH_REQ = 0x13,//End Upgrade
    START_RSP = 0x21,//Start Upgrade Response
    PACK_RSP = 0x22, //Upgrade Package Response
    FINSH_RSP = 0x23,//End Upgrade Response
}CMDID;//Command ID
typedef enum
{
    POWER_DEV = 0x31,//Power Board
    PANEL_DEV = 0x32,//Panel
}DEVID;//Device ID
typedef enum
{
    RSP_OK = 0x41,  //Correct Response
    RSP_ERR = 0x42, //Error Response
    RSP_FAIL = 0x43,//Failure Response
}RSP_CODE;//Response Code

1. Start Upgrade Request Content

• cmdID: START_REQ

• content: Firmware size + firmware signature information

1. Start Upgrade Response

• cmdID: START_RSP

• content:

• RSP_OK: Successful response, the host can proceed with the subsequent flashing process

• RSP_ERR: Error response, command recognition error, the host needs to retransmit the start upgrade request

• RSP_FAIL: Failure response, current conditions do not meet the upgrade or the transmitted upgrade is illegal (firmware size exceeds the legal range)

1. Upgrade Package Request

• cmdID: PACK_REQ

• content:

• Package Index: Value range 0~0xFF, accumulates to 0xFF and resets to 0 for the next package

• Package Size:

• Package Content: Content specified by the firmware package sending offset address

1. Upgrade Package Response

• cmdID: PACK_RSP

• content:

• RSP_OK: Successful response, the host can send the next package

• RSP_ERR: Error response, upgrade package verification failed (index verification, signature verification), the host needs to retransmit the previous package

• RSP_FAIL: Failure response, total size of the upgrade package exceeds the size requested at the start, upgrade failed

1. End Upgrade Request

• cmdID: FINSH_REQ

• content: NULL

1. End Upgrade Response

• cmdID: FINSH_RSP

• content:

• RSP_OK: Successful response, upgrade package verification successful

• RSP_ERR: Error response, command parsing error, the host needs to retransmit

• RSP_FAIL: Failure response, upgrade package verification (size verification, signature verification) failed, upgrade failed

4. Key Processes

4.1 Overall Upgrade Interaction Process

4.2 BOOT Software State Diagram

4.3 BOOT Software Main Process

4.4 Device Upgrade Process

4.5 Host State Transition

4.6 Host Flashing Process

5. Driver Interfaces

• Device Side

1. Serial data sending and receiving

2. FLASH erase, read, write

3. SRAM read, write

4. Jump to specified address execution

5. Data verification interface

• Host Side

1. File read and write

2. Serial data sending and receiving