Bootloader topic

[mabl]

Dear all,

I'm currently looking into developing my own bootloader, but I'm not sure if I'm doing it correctly. So here are several questions currently on my mind:

• Is there a define somewhere which gives me the flash page size and number of pages?
• Regarding flash wearing: Does the flash wear down on page erase only, or also during writing the 0's?

Things one has to take care of when developing your own bootloader:

• Before jumping to the user application, deinitialize all peripherals you used with sdStop(&device) etc.
• After Erasing a page deselect the FLASH_CR_PER bit (it's not done automatically)
• In the user application the only thing you have to do is to define the new flash start in the linker script and set CORTEX_VTOR_INIT to the new offset (best in chconf.h).

[Giovanni]

Is there a define somewhere which gives me the flash page size and number of pages?

No but the platform macro (STM32F1XX_MD for example) would give you the possibility to define them depending on platform.

Regarding flash wearing: Does the flash wear down on page erase only, or also during writing the 0's?

Not sure but I think erase operations do the most wearing.

Before jumping to the user application, deinitialize all peripherals you used with sdStop(&device) etc.

The STM32 HAL resets all peripherals on initializations, not sure if this is enough. Probably the NVIC must be uninitialized explicitely.

[Jacon]

[*] Is there a define somewhere which gives me the flash page size and number of pages?

One of the serious weaknesses of STM32F's - lack of that info embedded into chip
Mentioned countless times on official STM32 board, but without any response from ST...

[Giovanni]

Heh,

I reported a lot of errors in headers and the errors are still there...

Probably people making decisions and those working on the code do not read the forum.

Giovanni

[mabl]

Before jumping to the user application, deinitialize all peripherals you used with sdStop(&device) etc.

The STM32 HAL resets all peripherals on initializations, not sure if this is enough. Probably the NVIC must be uninitialized explicitely.

Strange, I ran into issues before, but now it seems to work without the *Stop() calls... For unititializing the NVIC, is such a code ok?

Code: Select all

  for(i=0; i<8; i++)
    NVIC->ICER[i] = NVIC->IABR[i];

[mabl]

Ok, I think I got most things up and running. I've added a github repo here:

https://github.com/mabl/ARMCM3-STM32F107-BOOTLOADER

[Giovanni]

Excellent work, you should be able to save some extra RAM/ROM space this way:

Code: Select all

#define CH_TIME_QUANTUM                 0
#define CH_USE_REGISTRY                 FALSE
#define CH_USE_WAITEXIT                 FALSE

You could also save a thread by using the loop in the main() for the blinker or the flasher.

Giovanni

[mabl]

Hi Giovanni, thx for the kind words. There are of cause still some rough edges and I did not optimize for RAM usage. For example I modify each page first in memory before it is written back - so this already needs 2K...

I've moved the blinker thread into main. The MMCFlasherThread uses fatfs and would hence need a bigger main stack.

Known limits of my bootloader:

• One could add exception handlers which catch exceptions on jump to the user application.
• The bootloader expects that there is no page protection in place. But I guess there is no need for IP protection in our firmwares...

[Jacon]

Sorry - can't delete this..

[wbober]

Hi mabl,

Thanks for making the bootloader available, exactly what I was looking for! An example of an application which can be loaded using the bootloader would be really useful though. Could be just a simple bilnker - just to show where to put change CORTEX_VTOR_INIT and how to init/deinit it.