cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4 Bootloader and user program

benoit2
Associate II
Posted on March 16, 2015 at 17:31

Hi,

I'm using an STM32F4 and i'm able to use a bootloader to Flash my user program at 0x08010000.

I still have 2 questions :

How this condition test the user code starting address ?

        /* Check Vector Table: Test if user code is programmed starting from address

               ''APPLICATION_ADDRESS'' */

        if (((*(volatile uint32_t*)APPLICATION_ADDRESS)& 0x2FFE0000 ) == 0x20000000){

My code is working but i had to remove this condition because in my case

(*(volatile uint32_t*)APPLICATION_ADDRESS) == 0x2002d9f8

Is it possible to configure my user program in order to use it without the bootloader but from another address than 0x08000000. So for example is it possible to  Flash and debug a program located in 0x08010000 ?

7 REPLIES 7
Posted on March 16, 2015 at 18:02

It's testing that the SP (Stack Pointer) is in RAM on the 1MB FLASH, 128KB+64KB die, ie F407, F405, F417, etc

For the 2MB FLASH 192KB+64KB die you'd need to modify the test.

It's a crude test, the erased FLASH would contain 0xFFFFFFFF, a more effective test would be to CRC you're whole application image to confirm that it is intact.

In most debuggers you can set PC to what ever valid value you chose. The processor isn't going to go anywhere but the default/standard addresses when it resets.

So a) either put some stub code in the boot loader position which transfers control directly to the application, or b) just leave boot loader in place, and debug the application when it get's there. In Keil a ''run to main'' of the application breakpoints the main() in the application, code runs until it gets there, and it stops, just like most any other debug session.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
benoit2
Associate II
Posted on March 18, 2015 at 17:40

Hi,

Thanks for your quick reply. I still have some issues. I'm able to flash my user app the first time. (my flash is fully erased, i flash my bootloader, i flash my user program from bootloader everything OK) but if i change the binary (new version), my bootloader doesn't jump anymore to my user porgram. I have to erase the flash, flash once more my bootloader and then it works and so forth and so on.

I'm probably missing something because when i am stuck, if i erase (user prog area), build, flash and start debugging the user program, jump from bootloader is OK...

Do you have an idea of why does it work when i start the debugger and not if i flash directly a new version with my bootloader ?

cheers,

Posted on March 18, 2015 at 17:50

The debugger moves the goal posts because it knows a thing or two about your application, and it's entry addresses?

You need to debug the boot loader more, and walk through the hand over code. Things like RTOS (privilege run state), and interrupts left dangling by the boot loader will bite you.

Instrument your code with USART, GPIO or LED output to track your code state so you don't need the debugger to know what's going on.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
benoit2
Associate II
Posted on March 19, 2015 at 17:50

I use FreeRTOS in my user code but not in the bootloader section. I wonder, when the program perform an erase of some sectors, this should set data in flash to 0xFF ? I tried to force this behaviour (because FLASH_If_EraseSectors didn't seem to reset the flash memory) by writing FFFF in all the Flash from my user app address. I can't see any changes in my memory.

When i flash with my bootloader on a blank (FF) area it's ok, when flash once more the erase doesn't work and i get wrong datas. What happens if i flash a binary on another binay ? Could it leads to weird data ?

Posted on March 19, 2015 at 19:19

You have to erase it, and then write to it once. At least some STM32 architectures use hamming or parity bits on the flash memory, and it's generally not conducive to being rewritten. Most flash cells you can keep writing until each cell is zero.

If the erase isn't working properly then analyze why, and if error status is being returned by the routines, or you are at the wrong privilege level.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
benoit2
Associate II
Posted on March 19, 2015 at 19:24

Of course there is no Error Status returned. What do you mean by privilege ?

Posted on March 19, 2015 at 19:34

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDIGFCA.html

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..