Re: STM32F7 bootloader based on ChibiOS
Posted: Mon Apr 29, 2019 8:07 pm
Just FYI:
If I'd write such a bootloader, I'd link the bootloader to <top-of-flash>. When bootloading, the bootloader will write all application bytes, except for the vectors at 0x08000000 (8 bytes). Those need to be stored somewhere else. Downloading the bootloader to the chip is now a bit more difficult: you have to flash the first 8 bytes and the bootloader at the end. But now writing and linking an actual application program is like running on bare hardware: no changing of normal ld files etc.
Oh, and another thing: To jump to the application, with the CPU as much as possible in "reset condition" is difficult. I't think it is doable with the RCC, but if you get stuck, consider the following: To get the CPU in pristine state, set the watchdog timer to go off "soon". Store a "magic word" in ram somehwhere, and when the bootloader "boots", it checks that word before doing anything else. If it sees the magic, disable the watchdog, remove the magic, and jump to the application. Now you've had a hardware reset that should have done "everything right".
Putting the CPU back in "pristine state" is difficult. For example, ST gets it wrong in the ROM bootloader (at least for the STM32F072). When you ask the bootloader to "jump to application" your application will find the internal RC trimmed at -8% (about 7.36 MHz). They set the RC trim register to zero while the five bit reset-default is 0x10 (halfway between 0x00 and the max 0x1f). Async serial connection become "flaky" at -8% trim......
If I'd write such a bootloader, I'd link the bootloader to <top-of-flash>. When bootloading, the bootloader will write all application bytes, except for the vectors at 0x08000000 (8 bytes). Those need to be stored somewhere else. Downloading the bootloader to the chip is now a bit more difficult: you have to flash the first 8 bytes and the bootloader at the end. But now writing and linking an actual application program is like running on bare hardware: no changing of normal ld files etc.
Oh, and another thing: To jump to the application, with the CPU as much as possible in "reset condition" is difficult. I't think it is doable with the RCC, but if you get stuck, consider the following: To get the CPU in pristine state, set the watchdog timer to go off "soon". Store a "magic word" in ram somehwhere, and when the bootloader "boots", it checks that word before doing anything else. If it sees the magic, disable the watchdog, remove the magic, and jump to the application. Now you've had a hardware reset that should have done "everything right".
Putting the CPU back in "pristine state" is difficult. For example, ST gets it wrong in the ROM bootloader (at least for the STM32F072). When you ask the bootloader to "jump to application" your application will find the internal RC trimmed at -8% (about 7.36 MHz). They set the RC trim register to zero while the five bit reset-default is 0x10 (halfway between 0x00 and the max 0x1f). Async serial connection become "flaky" at -8% trim......