1
2
3
4
5
6
7
8
9
10

typedef void (*load)(void);
void jump(uint32_t addr){
    if((*(uint32_t*)addr >= 0x20000000) && (*(uint32_t*)addr < 0x20000000 + ram_size)){             //Here 0x20000000 is the starting address of RAM, this checks if the jump address data is in RAM
        __set_MSP(*(uint32_t*)addr);               
        load = (load)* (uint32_t*)(addr + 4);
        
        SCB->VTOR = addr;                                    //This is the newly added statement
        load();
    }
}

In other projects, I also encountered situations where OTA needed to be performed on M0 series chips. In cases where the corresponding register cannot be directly accessed, it becomes a bit more troublesome, as we need to manually relocate the interrupt vector. The general idea is to copy the entire interrupt vector table to RAM before jumping, and then remap the vector table pointer address to the starting address of RAM (following the example above, mapping it to 0x20000000). This would involve using a remap function from the corresponding STM32 library. However, unfortunately, because the board I developed does not use the STM standard library, there is no such function, so I have not yet found another way to implement this functionality. If there is a similar need, you can look up relevant materials on M0 series Bootloader implementations; I have not actually verified them, so I will not elaborate here.

Bootloader Can Only Jump to One of the Dual APP Partitions

Dual APP partitioning was the first method I conceived to implement OTA without an EEPROM, which means dividing into Bootloader + flag + AB areas. The OTA update idea is as follows: 1. The program starts and defaults to entering Area A; 2. An OTA request occurs, and the new program is written to Area B; 3. If the write is successful, the flag at the corresponding address in the flag area is set to valid; 4. The program enters an infinite loop, and the system is rebooted by the watchdog; 5. After the Bootloader verifies the program, it jumps to Area B for execution, at which point Area A becomes the new download area.

The advantage of the above method is that it always ensures one partition has an executable program, so even if OTA fails or the write is forcibly interrupted, there is still a valid area that can be executed. In addition, it effectively utilizes the program flash space, reduces the number of erase/write cycles for a single area, and extends flash lifetime.

However, the above method overlooks the program's own address pointer issues. After compiling with various tools, the binary executable file we obtain actually retains information such as the program's starting address. This address information is generally at the beginning of the .bin file (which is essentially the interrupt vector table address mentioned in the previous issue). When the hardware executes the .bin program, it first reads this address information and jumps to the corresponding location to execute. In reality, if we set different burning locations for the same program, the compiled .bin files generated will be different. The comparison below can make this more intuitive: From the differences in the data segments of the divided sections, it is clear that the header data segments are different. If we simply burn the same program (compiled to be flashed into the same flash region) into different regions, even if the Bootloader jumps the program to the correct location, when the program reads the initial fields, the interrupt will jump back to the original region. This means that when writing a new program, we need to know the target burning address in advance during compilation, otherwise, region jump errors will occur. This is very inconvenient for subsequent OTA upgrades, so this method cannot be used directly.

Solution

1. Modifying Header Fields in the Program [Not Reusable]

This method involves modifying the header fields of the OTA program within the program itself, based on the OTA target address stored in the flag area. From the comparative data in the image above, it can also be seen that the header field repeats a certain value in a specific range. This field value is roughly program burning target address + some offset. However, I have not yet found a pattern for what this specific offset is; it seems to vary for different programs. Considering that the project aims to eliminate such unstable factors as much as possible, this solution has not been adopted for now.

2. Modified Scheme: Program Area + Download Area

Simply put, the goal is to avoid jumping to different regions and try to always jump to a fixed region upon each startup. Set Area A as the APP area; when running OTA, download the program to Area B, then write OTA flag information and CRC checksum information to the flag area, and reboot via the watchdog. In the Bootloader program, verify the correctness of the program in Area B, then copy it to Area A for execution, and finally reset the flag area information.

Of course, the above scheme has issues regarding operational stability: the Bootloader's startup efficiency will decrease when OTA is needed, and it's also difficult to guarantee the correctness of the copied program. Therefore, it's best to use external EEPROM or flash to solve the problem of temporary storage for OTA programs.