STM32F2xx Bootloader Sectors allocation

[dimax]

Posted on June 15, 2013 at 08:00

HI,

I'm starting to implement my own bootloader for STM32F2xx. Currently I plan to support UART, USB and ETH. Also I plan to use EEPROM emulation.

Implementation of USB and ETH (TCPIP Socket) takes about 30K. So To be on a safe side I plan to use following Flash sectors allocation:

Sector0 16K - Bootloader

Sector1 16K - EEPROM Emulation Page0

Sector2 16K - EEPROM Emulation Page1

Sector3 16K - Free

Sector4 64K - Free

Sector5 128K - Free

....

SectorN 128K - Bootloader (Last Sector depending on Flash size)

Sector0 has to be used by Bootloader as this is where a RESET will be fetched.

Sectors 1,2 has to be used for EEPROM emulation.

Free sectors can be used by Application.

If my approach is correct I need to create linker - ld file with gap inside. I wonder if there is a any better idea to implement all above.

Thanks.

[Tesla DeLorean]

Posted on June 15, 2013 at 13:45

Sectors 1,2 has to be used for EEPROM emulation.

Why? It's an abstraction, change it.

[dimax]

Posted on June 15, 2013 at 15:23

EEPROM Emulation requires 2 sectors. Using 128K sectors for EEPROM emulation is a huge spend of memory. So I have only three 16K Sectors 1,2,3 left for EEPROM. If I take 1 & 2 at least application FW will have no gap.

I wonder if linker supports gaps? I'm using yagrto GCC.

[Tesla DeLorean]

Posted on June 15, 2013 at 15:37

Ok, if I needed 32K I'd move the EEPROM emulation up a sector.

GNU/GCC and frankly Keil are not particularly friendly in spanning sparse regions of memory. It usually requires some manual floor planning to direct specific objects (files), or functions into specific regions.

If the wasting of the front 16K is of little concern, I'd simply park the vector table there, and perhaps the BSS initialization data, and place the loader code in the 64KB sector. You could use the 128KB sector, but it seems excessive and takes space that could be used for the application.

You could achieve this level of partitioning with a simple linker script / scatter file modification.

[dimax]

Posted on June 15, 2013 at 16:10

Remember the sectors allocation in STM32F2xx:

Sector0 16K - RESET Bootloader

Sector1 16K - EEPROM Emulation Page0

Sector2 16K - EEPROM Emulation Page1

Sector3 16K - Free

Sector4 64K - Free

Sector5 128K - Free

.....

I have to use Sector0 for bootloader as it is a RESET address fetch place.

So I can't move EEPROM emulation higher then Sector1,2

If I put bootloader in Sector 4 (64K)  there is a gap unless I give up for Secotr3.

So I think to stay with my initial allocation with bootloader in last 128K sector. At least application will have no gaps in this case. Also we plan to put a lot of features in bootloader so 128K is not so bad.

I liked a much your idea to use Sector0 for Reset vectors and BSS only. This will save my time from dealing with a gap in text section.

Well after old good AVR Mega architecture with build in EEPROM and special BOOT sector and reset vector and clear protection scheme, all above looks a nightmare. I do not understand why ST did not think about so basic features for Embedded CPU while they put a lot of other bizarre features inside a chip.

 

[Tesla DeLorean]

Posted on June 15, 2013 at 16:22

So I can't move EEPROM emulation higher then Sector1,2

You keep telling me that, but it's an abstraction you control, you could put it in 2 & 3 if you put your mind to it.

[Tesla DeLorean]

Posted on June 15, 2013 at 16:36

Well after old good AVR Mega architecture with build in EEPROM and special BOOT sector and reset vector and clear protection scheme, all above looks a nightmare. I do not understand why ST did not think about so basic features for Embedded CPU while they put a lot of other bizarre features inside a chip.

But stand-alone flash devices with boot blocks, and top/bottom variants, are hardly a new thing. The partitioning here relates to efficiency of address decoding in silicon (critical paths/speed), and the way the hard flash blocks are designed. Older STM32 parts had uniform 1K or 2K blocks, but this isn't very efficient when you have 1MB of flash to place. The RAM and FLASH represent the majority of the die, the Cortex-Mx is a fraction part.

When you can afford to do an SoC you get to make the design choices, for a general purpose part others get to make the efficiency/efficacy trade offs. What bizarre features get bolted on usually depends on drivers from BIG customers, and check list items.

[dimax]

Posted on June 16, 2013 at 06:52

I understand I can use Sectors 2,3 but it gives me nothing as in this case Sector1 is unused.

32K for bootloader is not enough for me.

[dimax]

Posted on June 16, 2013 at 07:13

But stand-alone flash devices with boot blocks, and top/bottom variants, are hardly a new thing. The partitioning here relates to efficiency of address decoding in silicon (critical paths/speed), and the way the hard flash blocks are designed. Older STM32 parts had uniform 1K or 2K blocks, but this isn't very efficient when you have 1MB of flash to place. The RAM and FLASH represent the majority of the die, the Cortex-Mx is a fraction part.

 

 

I do not say to change partitioning. I'm talking about one small thing - To have a bit in OPTIONS that will control a reset start address to move it from 0x00000000 to let's say beginning of the last Flash sector lets call it bootsector. This is what they have done in AVR. If this bit is set chip will start from bootsector

 

When you can afford to do an SoC you get to make the design choices, for a general purpose part others get to make the efficiency/efficacy trade offs. What bizarre features get bolted on usually depends on drivers from BIG customers, and check list items.

 

 

Don't think having 2-4K of EEPROM on chip is something so complex. I'm not familiar with any serious commercial embedded application that does not need EEPROM to store configuration data with ability to change it. I asked a number of my friends working with ST, they all faced this problem and had to use mostly external I2C or SPI Flash/EEPROM to work it around. I'm going to use EEPROM emulation.

ST made a really powerful chip that bits all competitives in cost/performance. But it's still not perfect and architecture level of chip is not as professional as Atmel does.

The good indication for it is a luck of comprehensive data sheet with clear explanations. (I do not say that it has a lot of mistakes including English spelling and grammar).

In many cases you have to strictly follow sample code without any possibility to understand why it should be done so as data sheet does not explain architecture behind it and meaning of many CR bits is not clear. I'm working for silicon company and I know that if datasheet is not complete it means silicon design is bad. It's still working somehow but it's bad.

[zzdz2]

Posted on June 16, 2013 at 10:17

I understand I can use Sectors 2,3 but it gives me nothing as in this case Sector1 is unused.

 

32K for bootloader is not enough for me.

 

Use sectors 0-4 for bootloader and EEPROM, no need to waste the last 128k for boot.