booting from bank 2 of STM32F4x9_eval

[tonyyu]

Posted on October 24, 2013 at 19:44

I run a program fine on bank 1. Then programmed BFB2 to 1. (BOOT0 = 0).

Compile Blinky to 0x08100000 and load it. Checked the flash by stlink-util and see

0000: 20000468 081001c1.

Those are correspondent to the .map file of STACK and reset_handler. Ok, good to go.

Of course it won't work.

I fired up the Keil debugger. found it began at 0x1fff 4abe, it's the bootloader. Fine, which is consistent to document. When BFB2 is 1, it will go to boot loader, then jump to bank 2.

content on memory windows that shows normal too.

then after a few steps (0x1fff4ac6). PC become 0x081001c0. all the flash contect become FF. I checked again the content by stlink. It's still valid, not FF. and of course. The PC is not the address of reset_handler. 

Somewhere in bootloader didn't go as I hope. (load SP from 0x08100000, and jump to 0x08100004 -> 0x081001c1 (reset_handle).). 

I wonder what's go wrong....

The hardware is the STM32F4x9_EVAL.

Sink

[Tesla DeLorean]

Posted on October 24, 2013 at 21:09

Review the memory subsequently mapped at ZERO and 0x08000000

[tonyyu]

Posted on October 24, 2013 at 21:28

Hi,

I fail to see anyplace that defined 0x08000000. And for those 0. which is from the .s file

__Vectors       DCD     __initial_sp               ; Top of Stack

                DCD     Reset_Handler              ; Reset Handler

                DCD     NMI_Handler                ; NMI Handler

                DCD     HardFault_Handler          ; Hard Fault Handler

                DCD     MemManage_Handler          ; MPU Fault Handler

                DCD     BusFault_Handler           ; Bus Fault Handler

                DCD     UsageFault_Handler         ; Usage Fault Handler

                DCD     0                          ; Reserved

                DCD     0                          ; Reserved

                DCD     0                          ; Reserved

                DCD     0                          ; Reserved

                DCD     SVC_Handler                ; SVCall Handler

                DCD     DebugMon_Handler           ; Debug Monitor Handler

                DCD     0                          ; Reserved

                DCD     PendSV_Handler             ; PendSV Handler

                DCD     SysTick_Handler            ; SysTick Handler

So, I still don't get what goes wrong.

Sink.

[Tesla DeLorean]

Posted on October 24, 2013 at 21:49

The hardware swaps Bank1 and Bank2 in the memory space, and can then map at zero.

Change your memory view window to 0x08000000 in the debugger

[tonyyu]

Posted on October 24, 2013 at 23:43

I am stuck now. It seems that in order to boot from bank2. I need to build/link the program at 0x08000000, but load it to 0x08100000. So later when bootloader make the address swap. it can run correctly. Is that right?

When I tried to do that. I found neither Keil flash programmer nor STLink-util allow me to load hex file that build 0n 0x08000000 to 0x08100000. 

Is there application note document the dual boot mechanism beside AN2606? what's the correct/normal procedure?

Regards,

Sink

[Tesla DeLorean]

Posted on October 25, 2013 at 00:31

I'd supposed you'd compile/link for 0x08000000, and instead of using a .HEX, you get FromELF to make a .BIN file, which doesn't infer a load address, and then get the ST-LINK utilities to load the .BIN and program it at 0x08100000 from there (Start Address in Download dialog).

[Tesla DeLorean]

Posted on October 25, 2013 at 00:53

I haven't at this juncture reviewed the App Note in question, I've been reviewing the Reference Manual and playing with the silicon. I played with the mapping register some time ago in terms of swapping the Flash Banks, and also the SDRAM.

Shadowing ROM files at different addresses, and compiling/loading files at assorted addresses is relatively straight forward from a Boot Loader perspective. I haven't spent a lot of time pondering how I might get Keil to program to the high bank, but I suppose it could be done with an INI script to program the bank mapping registers, or customizing the Flash Applet. Programming the upper bank seems more of a production exercise than a debugging one, and part of the job of the boot loader. Certainly from the perspective of programming, upgrading and managing alternate application images.

I'd probably tend more toward keeping a 16KB boot loader, and staging an update in the upper bank, rather than ping-pong between the two, although I can see the advantage of being able to regress. That said most of the interest has been in getting ~2MB of app space, and staging updates on an SD Card, or running larger apps from SDRAM.

[Tesla DeLorean]

Posted on October 25, 2013 at 01:18

Took a look at the

http://www.st.com/web/en/resource/technical/document/application_note/CD00167594.pdf

, does all seem rather contrived, kind of pushes off the responsibility of the Boot Loader to the System Loader. The sanity checking for the app doesn't seem to be very robust, basically checking if Stack resides above 0x20000000, as best I can tell. I'd rather it check the integrity of the whole image rather than a single page, or a couple of words at the front end. Flashing tends to write in a linear fashion so a write failure deeper into the image won't be caught.

The prime benefits being not changing the mapping of running code, no app code changes, and how the address swapping is handled by ART

[tonyyu]

Posted on October 25, 2013 at 01:28

Yeah, currently I convert .hex to .bin then program to high bank to achieve the dual bank booting of the system that require golden/current image operation. 

I tried to set up .sct file like 

LR_IROM1 0x08100000 0x00100000  {    ; load region size_region

  ER_IROM1 0x00000000 0x00100000  {  ; execution address

   *.o (RESET, +First)

   *(InRoot$$Sections)

   .ANY (+RO)

  }

  RW_IRAM1 0x20000000 0x00030000  {  ; RW data

   .ANY (+RW +ZI)

  }

}

to see if I can make Keil to work as I want. But then I got

'cannot be assigned to non-root region' error. 

so I didn't find 'simple way' to do high bank linking/flashing yet. 

Sink.

[omer Korech]

Posted on June 14, 2018 at 15:59

Hi Sink

We are facing the same problem

My

approach 

to achieve '

high bank linking/flashing'

 is followed:

1) Flash the program to bank1 (as usuall, when no bootloading is considered)

2) The program contains a function, that when triggered, copies its own ontent to bank 2 (note that bank 2 need to be first erased by the same function, otherwise copying the code fails)

3) Towards the end of the aforementioned function, The program checks for the value of BFB2. If it points to bank1, it toggles its value (HAL_FLASHEx_AdvOBProgram can be used)

4) Reset the device

In order to verify my approach works, another step should that corrupts bank1 is to be added.

Not sure it works 100% will update after some debugging and experimentation

[omer Korech]

Posted on June 19, 2018 at 19:23

It seems my suggestion to copy the code from bank1 to bank2 should have worked for stm32l0xxx and stm32l4xxx, where memory remap for bank swapping is supported. However, for my stm32l15x, the code in bank2 need the linker file to be configured to bank 2. This is easily achieved in IAR. In addition vtor is to be configured to point to bank2 in the SystemInit(). Last but not least, nBFB2 is to be reset once, possibly buy a code running from bank1.

This solution enables fail safe firmware upgrade of bank1 using st built in boot loader that resides in system memory. In case of failure the code from bank2 is run. However, since bank2 is only partially accessible by st boot loader (128 Kb out of the 256Kb are accessible), bank2 cant be updated by long ( > 128Kb) firmwares. So the back up code is always the original factory code and cant be updated.