Bootloader topic

[mabl]

Hi wbober,

I think it would be more useful to just state the things you need to change for your program to work with any boot loader:

• First, figure at which address your bootloader expects the user program to be. In my example this is set in flashconfig.h as FLASH_USER_BASE and is in this case 0x08005000. Remember this number.
• Now you need to change your user program to be located at this location. You need to change only 2 settings:
  
  • Your linker script:
    
    • By default your makefile uses a standard chibios linker script. In our case os/ports/GCC/ARMCMx/STM32F1xx/ld/STM32F107xC.ld.
    • Copy it into your project folder. And modify LDSCRIPT in your makefile to point to your new linker script. (You might want to test if your project still compiles.)
    • Modify the starting point of your flash in the linker script. This the flash : org = 0x08000000, len = 256k line. Just replace 0x08000000 with the address you remembered above. (You might also reduce the length of the free flash space, but it is not so important..)
  • Your program should still compile - but not work.
    
• The start of your interrupt vector jump table. Which was originally at 0x08000000 now moved to 0x08005000. Currently there is the boot loader at that place, so we have to tell the Cortex-M3 where to too look.
  
  • We can do this by adding the setting to chconf.h.
  • Add a define for CORTEX_VTOR_INIT to chconf.h pointing to address 0x00005000. Do not worry about the missing 8 in the address. The processor does a internal mapping of the flash/ram...

You should now be able to flash the program via the bootloader. It might also work to flash it directly over jtag (if you do no flash mass erase) since you will only start writing flash at 0x08005000 and the bootloader is preserved and will just jump to your user application.

[Badger]

You might also reduce the length of the free flash space, but it is not so important..

This is true until you creep over the flash limit of your MCU but not the ld script (because the start address is now higher) and strange things start happening

[mabl]

You might also reduce the length of the free flash space, but it is not so important..

This is true until you creep over the flash limit of your MCU but not the ld script (because the start address is now higher) and strange things start happening

Hehe sounds like you are talking from experience.

Ok so if you want to change the flash length:

• You need to figure out how much space your boot loader takes.
• Since the user program starts now with an 0x5000 offset, the program starts 0x5000/1024 = 20 Kilobyte later. So reduce the 256k flash ROM by 20K.
• This yields flash : org = 0x08005000, len = 236k

[wbober]

Thanks guys. I'll give it a try!

Wojtek

[mobyfab]

You should check this one: https://github.com/leaflabs/maple-bootloader

[Xamusk]

Just for reference, I posted my linker script on this topic:
viewtopic.php?f=3&t=456

[talsit]

And I've forked the bootloader and made it run for STM32F4.
Since the memory layout is totally different to the F1, and the flash interface registers too, I decided to just basically start from scratch, leaving basically the error defines and a little bit more.

https://github.com/talsit/kuroBox_bootloader

It's customised to my board, which uses SDIO for the SD interface. I also have 2 buttons and 3 LED's. I require that the buttons be held down for 2 before proceeding, and you get some status feedback on the LED's. Those things should be quite easy to customise to your needs.

Since the STM32F4 has an "interesting" memory layout (4x 16kb, 1x64kb, 7x128kb sectors), I've decided to start the user app at sector #5, which is 0x0802000, so 128KB in, which is the start of the 128kb-sized sectors.

For the target (flashed app, not bootloader) to work, you need to what is very well summarised here:
viewtopic.php?f=3&t=417&start=10#p4208

Enjoy and feedback, as always, is most welcome!

[M1Sports20]

I just wanted to add a note that at least on the STM32F2 you must have your vector table alignment correct. I spent a couple of hours debugging this. I stored a small header before my image and vector table.

I am not positive what the alignment needs to be, but I believe it depends on how many interrupts your using or ChibiOS is using.
Source: http://infocenter.arm.com/help/index.js ... cbadd.html

To be safe I believe you must align to 0x200 to allow all interrupts to be useful

[theShed]

The vector table must be aligned to a 'block boundary' where the block size is the size of the vector table itself.

So a minimal 32 entry vector table must be aligned to:
32*4 = 128 (0x80) byte boundary.

and an STMF4xx with its 90+ entry vector table must be aligned to:
128*4 = 512 (0x200) byte boundary

I can't think of a part with a larger vector table so you should be OK with a 0x200 alignment....

--
mike

[DeusExMachina]

Hi wbober,

I think it would be more useful to just state the things you need to change for your program to work with any boot loader:
...
[*] The start of your interrupt vector jump table. Which was originally at 0x08000000 now moved to 0x08005000. Currently there is the boot loader at that place, so we have to tell the Cortex-M3 where to too look.

• We can do this by adding the setting to chconf.h.
• Add a define for CORTEX_VTOR_INIT to chconf.h pointing to address 0x00005000. Do not worry about the missing 8 in the address. The processor does a internal mapping of the flash/ram...

[/list]
...

OK, but how about STM32F051?
CORTEX_VTOR_INIT is used in _port_init() from chcore_v7m.c, but this function is not defined in chcore_v6m.c. How to move interrupt vectors in this case?