This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Bootloader+Flash uVision program for Keil STM32F400 kits

Hi,
I'm trying to learn more about bootloading and flashing the boot code for a MCBSTM32F400 kit (Board Eval for STM32F400) and I see that in the example code there are several uVision projects for other eval board (such as LPC31xx where as an example a Bootloader_NAND.uvproj exists - which has both boot loader code and a FlashHW.c file for flashing) but there isnt anything for this kit/eval board. Would anyone be able to point me towarda uVision project that includes example bootloader and flash source code (that I can build in uVision).

Sorry for including this is th eARM7/ARM9/Cortex-M3 as there isnt a category for M4 (although probably similar to M3). Interesting that no bootloader+flash examples at all under /Keil/Boards/Keil/*.

Thanks in advance, Dean

Parents
  • 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.

Reply
  • 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.

Children
  • 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.