Modify the start address 0x800 0000

[eancelin]

Posted on June 26, 2012 at 16:26

Hi,

My microcontroller is a STM32F103CB.

I followed the AN2557 to do an IAP in my software. Everything works fine but now I would like to do something like a dual bank features.

I can flash two firmwares at two different address in flash (for example, one @0x8003000 and the second @0x8006000) but when my IAP software starts (@0x800 0000), if I do the classical test ( if (((*(__IO uint32_t*)ApplicationAddress) & 0x2FFE0000 ) == 0x20000000) ) the first bank will be still OK, so I never start the firmware in the second flash.

Is there a way to set an option to know which ''bank'' is activated?

Is there a way to modify by software the start address (modify the 0x800 0000 address)?

I hope my request is enought clear!!

Regards,

#flash #groundhog-day #start-address #iap #stm32

[Tesla DeLorean]

Posted on June 26, 2012 at 16:47

No, not really. You can change the BOOTx pins to change whether is boots from different addresses, ie FLASH (0x08000000), ROM (0x1FFFF000) or RAM (0x20000000)

You can just add a very small amount of code in your boot loader to vector to whatever block or bank of code you want. Typically a boot loader would try to validate code before jumping to it.

I'd put this stuff in the Reset_Vector code path.

[eancelin]

Posted on June 27, 2012 at 09:27

Thanks for the answer. I will see how I can do this. What do you mean exactly by : ''I'd put this stuff in the Reset_Vector code path''. Where can I find this code?

''You can just add a very small amount of code in your boot loader'' : That's what I try to do but I need to have the information of the ''bank'' to use even if a reset is done or the power supply is switched off/on. Can I keep in ROM this information (for example : int valideBank = 0 or 1)?

[Tesla DeLorean]

Posted on June 27, 2012 at 13:00

The reset code is typically in the startup_stm32fxxx.s file, or equivalent.

If you have multiple applications you'd need to store which in an area of FLASH or EEPROM.

To validate an image as you boot you'd typically place a couple of signatures/markers in the image which the boot loader can check, and a checksum/crc at the end which confirms the image is complete and correct. This will catch if it was written/received properly, and if the flash array fails over time.

[eancelin]

Posted on June 28, 2012 at 10:11

I'm sorry but I don't known how I can add a signature in the firmware (image) to be read by the bootloader. Can you help me?

[holger]

Posted on June 30, 2012 at 15:57

You will have three partitions

1st bootloader

2nd Firmware Version A

3rd Firmware Version B

Each partition starts with the vector table __Vectors (see startup_stm32fxxx.s).

Append direct behind the vector table a signature,

EXPORT __Vectors

__Vectors

...

...

...

__Vectors_End

EXPORT _Signature

_Signature DCB ''...'',0

Now the check is simple

extern uint32_t *__Vectors,  _Signature;

uint32_t * FirmwareASignature = StartAdressFirmwareA + (_Signature - _Vectors);

uint32_t * FirmwareBSignature = StartAdressFirmwareB + (_Signature - _Vectors);

if (FirmwareASignature > FirmwareBSignature)

Start FirmwareA

else Start FirmwareB

Holger

[Tesla DeLorean]

Posted on June 30, 2012 at 16:31

I'm sorry but I don't known how I can add a signature in the firmware (image) to be read by the bootloader. Can you help me?

You could use empty vectors to provide pointers or sizes, ideally permitting a fixed location the boot loader can easily find. You could also search for strings/structures.

static const char sig[] = ''Foo Bar Corp.'';

You can add things via the linker script, or definition files.

You might also need to consider post link processing to handle and repackage a hex/bin image into a consistent form, adding sizing, signature and checksumming data. This might also include making the image a fixed size, and defining a fill character. This step could also potentially search the image for some special structures, encrypt or sign various components, and doing anything beyond the scope/capabilities of the linker. I'd consider this to be some basic ''stdio'' file handling and manipulation, but you'd need to grasp the representation of the code/data, and how the CPU and boot loader interact with it.

[eancelin]

Posted on July 03, 2012 at 10:44

Thanks for your answer. I will try it.

I also added at the beginning of the generated binary firmware a fixed bytes sized with the name, the date and the version of the firmware with a script.

I modify the vector_table address to take in account these information datas at the beginning.

It works fine at the moment. 

[duongcam1312]

Posted on July 18, 2012 at 10:17

I testing AN 2557 to use it update Firmware from FPT Server. I load Bin file into address 0x0800300 ok (see by STM32 ST-LINK Utility). And I set    VECT_TAB_OFFSET  0x3000 .But when I run, new Firmware not work. I also tested wirh  NVIC_SetVectorTable(NVIC_VectTab_FLASH,0x08003000) .

Please help me.thank you verry much!

Regards.

[Tesla DeLorean]

Posted on July 18, 2012 at 13:24

If the code is built/linked for the wrong address it will not work. You will need to insure that the linker script or scatter file reflect the address where you plan to place the code.

[duongcam1312]

Posted on July 19, 2012 at 03:35

Thanks for your answer. And I have problem want you explained to me 

code :    JumpAddress = *(__IO uint32_t*) (

ApplicationAddress + 4

);

             Jump_To_Application = (pFunction) JumpAddress;

                 /* Initialize user application's Stack Pointer */

             __set_MSP(*(__IO uint32_t*) ApplicationAddress);

             Jump_To_Application();

Why need ''

+4

'' ?    

Thank you verry much.