Bootloader+Flash uVision program for Keil STM32F400 kits

Thanks Westonsupermare Pier,

I appreciate the response. I'll look these over and see if I can use them to write an application program to flash.
Do you know if there is a risk of 'bricking' the eval board or is it the case that you can always recover (if you follows these application notes)? In the case of loading the program that does the flashing, do you have a choice as to where the application (that flashes) resides in memory, not sure if it resides in RAM or another section of flash (or is configurable).

Thanks, Dean

Hi again Westonsupermare Pier,

I looked over the application notes and maybe you could answer a question for me and see if I understand the idea here. I've looked at the note that covers the usage of the USART for flashing.

It looks like there is a built in boot loader at 0x1FFF77DE which is at the very end of the flash memory. I assume that the chip must be hard wired to boot from this location which either flashes the user app (from the KEIL MDK-ARM dev environment) or boots to 0x8000000. So would I be correct the reason the USART application note you pointed me to puts the flash program at 0x08000000 is that in actuality the chip boots to 0x1FFF77DE and since nothing is being flashed it just boots to 0x08000000 where the IAP flash app is located? Thats why the IAP flash app puts the users code at 0x08004000, because it has to put the flash app someplace and it would have to be 0x8000000 in order to run the IAP flash app.

So in actualy the embedded bootloader runs first, then the IAP flash app (to allow the user to flash their program). When the flashing is done and the board is reset the embedded bootload runs again, passes control to 0x08000000 (IAP) and then on to 0x08004000 (since the user has already done the flashing the users program can be run).

Seems like this works but then our always running 2 bootloaders, is this true? Is there anyway to flash something directly to 0x08000000 instead of 0x0800400? That would seem cleaner.

Not sure if I'm making any sense or not but thats how I'm reading things in the application notes (and trying to learn).

Thanks, Dean

You have most of the basic concepts there.

The BOOTx pins control if ROM (0x1FFFxxxx), FLASH (0x08000000), or RAM (0x20000000) get mapped at zero and represent the memory booted by the processor.

The "In System" mode where BOOT0 is High provides a USART(Flash Demonstrator) and USB(DFU) mechanism to program raw/blank devices. This is also referred to as the System Loader, and can be used to unbrick devices

To code your own loader you need it to live at 0x08000000, the first blocks are 16KB, so you could place the app at 0x08004000,0x08008000,.. These small blocks are quicker to erase and easier to manage, consider placing configuration/calibration data here if you need that or EEPROM emulation, and pushing out the app to 0x08010000. There is a lot of flexibility here, you just have to floor-plan the space to meet your needs.

Thanks Westonsupermare Pier,

Its making a lot more sense now. As you said if you need to code your own bootloader it needs to live 0x08000000 so it boots directly (no system bootloader is used).

Thanks, Dean

Westonsupermare Pier,

I'm trying to make sense out of the scatter file (.sct) with regard to the built-in (system) bootloader and how it knows to run the image from internal flash or internal ram.

In the case of internal flash it seems straightforward. The image is written to 0x08000000 (begin flash area) by the flash code (does it use the scatter file to know where to write the image?). The interrupt is set to run on reset at 0x08000000.

But in the case of internal RAM, how does the image get to the correct location. Again I could see the sacatter file being used but what actually writes the image to RAM, is it some sort of internal system program that I cant see (is it part of the system bootloader)? If it is and you want to have your own bootloader boot up, it would then have to be part of that application. Would it have to use system calls to write to the internal ram for the STM32F4xxx?

With these questoins I'm just trying to tie the bootloader together with the location of the code (image) and how the image gets written to the klocation where it is written to.

Thanks, Dean

The System Loader plays no part in picking FLASH/RAM images, there is no invisible hand, the BOOT0/BOOT1 pins control the device mapped at address zero, and consequently what takes control of the processor at reset.