2024-08-16 07:49 AM
Hi everyone, I'm developing a bootloader that works like this. I was inspired by the example: https://github.com/pramodk51/bootloader_for_stm32f4.
I developed this initially on Nucleo F439ZI for the test phase and I managed to implement it with the addition of DFU functionality. The principle was simply to send a program that lights a led per uart that the bootloader would store and then go to this memory location to make it work (2 slots, one for the recent version and the other for the backup).
Note: I didn't develop the whole thing in the same code, I have bootloader code and application code, so 2 linker scripts etc ...
Once the test was functional and robust, I decided to integrate it into my personal project. My application this time is much more complex than turning on a LED, it uses FreeRTOS and is also much larger (but respects the size specified in the slot).
In terms of the application I've reproduced exactly the same operation so that it adapts to the slot automatically with the
SCB->VTOR
. Obviously the code I generate is adapted to the slot in which it will be placed using the linker script.
So when it comes to restarting, everything should work in the same way as when I carried out my tests on nucleo. However, I'm not getting any results from my tests.
My application program won't launch even though the bootloader redirects to the correct slot and updates the reset handler (check against the .map). But after that I have nothing. I have an IWDG function on the bootloader and the application and at the end of each WDG delay I loop back to the bootloader because nothing happens.
My problem is that I'm reproducing exactly the same pattern as during my configuration tests and the result is different.
I suspect a difference in treatment when using FreeRTOS but I haven't found anything on the subject. Are there any parameters that need to be managed to ensure correct operation?
I apologise in advance for my lack of clarity and information. I don't want to confuse you with too many documents, so I'd rather give you the information you find relevant.
I'll leave it to you while I continue my research and thank the ST community in advance for reading me.
All the best.
Solved! Go to Solution.
2024-08-18 07:16 AM
OK, I'll find out tomorrow how to implement my program directly at address 0x08020400 via Utility.
However, I don't understand your question? Yes, in my ‘blink’ program I have no interrupts. Does this mean that it's a different process and that's why it only works with blink?
2024-08-19 05:48 AM
So I'm following up on the previous message. I tried to start the program directly at address 0x08020400 with ST_LINK_CLI and neither the APP program nor the ‘blink’ program worked. I think I must be doing it wrong. However, I still have the same problem: the test program works but the integration does not. If you have any other ideas, I'd love to hear from you.
2024-08-19 07:43 AM
Show your command line , hard to help when you dont debug. Primary your bootloader is fail, but without check run app without it you are lost
2024-08-26 10:46 PM
Hello everyone, here's a little feedback on this topic. Following these exchanges I decided to go back to my problem and I finally found that the solution was in the SystemClockConfig(), a flag error already raised for the clock, most probably due to the fact that I was setting the clock first in the bootloader and then in the application. Thanks to those who tried to help me.