0
\$\begingroup\$

I am trying to "read-while-erase" and "read-while-write" with my stm32f427 dual bank flash for firmware upgrade. what I need to know is how can the program dynamically figure out which bank it's executing from? so the code can calculate the flash address of the other bank where it need to start erasing from or write the new program to. Is there a bit or register I can check? Another question I have is..how do I move the vector table from one bank to another?

Thanks.

Link to the Refence Manual: http://www.st.com/web/en/resource/technical/document/datasheet/DM00071990.pdf

\$\endgroup\$
2
  • \$\begingroup\$ You should improve your question a bit, by adding a link for your component's datasheet for example. \$\endgroup\$
    – MaximGi
    Mar 2, 2016 at 8:00
  • \$\begingroup\$ Run the updater code on SRAM to make things easy. For the vector table, look for "Vector table offset register (VTOR)" on the programming manual of the part; it is PM0214.pdf for the f407. \$\endgroup\$
    – Ayhan
    Mar 2, 2016 at 15:04

1 Answer 1

2
\$\begingroup\$

If you're not doing anything special (like PIC (Position-Independent Code) - which I'm not that familiar with, and frankly not even sure if it's supported on the platform), the code must be linked against the memory area it's going to run in - thus the code should already know the bank it's [going to] run in. So just take the address of a function (or the linker symbol for start of code area), and check which bank the address falls in. (Although you'll probably need/have the information available elsewhere, too, since you're going to need it to link the new code against the proper bank)

If PIC is possible and you're using it, you'll have to read the instruction pointer. I haven't verified how this should be done, exactly, but I assume you'll have to hand-write an assembly function that returns the contents of the link register.

If PIC isn't possible and you just realized having to link code against different addresses is going to be inconvenient, another possibility is writing a small bootloader (it doesn't have to be a bootloader either, just a separate firmware upgrade blob) which handles the firmware upgrade. That way the bootloader can stay the same, and you can always write the code to the same memory location. (Or first write to second location, and then copy over to the correct location, to avoid problems if the transfer is interrupted)

Note that even if you went with code in two different banks, you'd need a bootloader or something equivalent - the reset vector sitting at the start of flash would need to point to some code that decides whether it should start executing the actual firmware from bank 1 or bank 2.

The bootloader suggestion is assuming you don't really need read-while-erase and read-while-write, though - and you don't need them just for firmware upgrade. They allow the code to continue executing while a part of the flash is being erased/written, but that's not required just for firmware upgrade, since it'll work fine even if the code blocks while the flash is being erased/written until the operation is complete, if there's no specific requirement for the main software to run normally while the firmware upgrade is happening. (And just in case you're doubting this: I've previously written a bootloader that upgrades firmware which is located in the same bank as the bootloader, and it works fine. So in addition to just theory, this works in practice, too! :)

As for moving the vector table, it depends on the model. For the STM32F4 (and F3) that you have, you can choose where the vector table is located by writing the (512 byte aligned) address to SCB_VTOR (Vector Table Offset Register). If you were working with STM32F0 parts, which do not have the SCB_VTOR register, you could use the MEM_MODE bits in the SYSCFG_CFGR1 register; they select what is mapped at address 0, where the vector table is read from: either the main flash, system flash (internal bootloader) or SRAM. Since you wouldn't be able to change the location inside flash, you'd want to select SRAM instead, and copy the vector table to the start of RAM.

\$\endgroup\$
7
  • \$\begingroup\$ I just noticed I missed the vector bank question; I'm in bit of a hurry right now, but I'll update the answer later - I can't remember the name of the register off the top of my head. (In SCB, IIRC, and it differs between model families) \$\endgroup\$ Mar 2, 2016 at 12:47
  • \$\begingroup\$ Thankyou Aleksi. I actually do need the code running in one bank while writing or erasing the second bank. The STM over here is responsible for managing the power supply to another MCU (TI OMAP) and the new firmware used for STM upgrade will be received VIA OMAP. So you see the STM shall be running the code at all times so that it can manage the power of OMAP so in turn OMAP can send the new firmware to STM. \$\endgroup\$
    – Ali
    Mar 3, 2016 at 3:57
  • \$\begingroup\$ Yeah, I was thinking of implementing something like Position Independent Code. But don't know how to dynamically figure out each time the current bank and the appropriate address for writing and erasing the flash. \$\endgroup\$
    – Ali
    Mar 3, 2016 at 4:06
  • \$\begingroup\$ There is Bit in user Option Byte called BFB2(Boot From Bank 2) used to switch between banks. I was thinking maybe the code can use the same bit for checking which bank it currently running in. This is what the Reference Manual says about it "To select boot from Flash memory bank 2, set theBFB2 bit in the user option bytes. When this bit is set and the boot pins are in the boot from main Flash memory configuration, the device boots from system memory, and the boot loader jumps to execute the user application programmed in Flash memory bank 2." \$\endgroup\$
    – Ali
    Mar 3, 2016 at 8:44
  • \$\begingroup\$ Follow up question to the vector table question I asked earlier. After the code has been written to bank 2 and I modify the SCB->VTOR register does that take effect immediately? Because there would be interrupts from OMAP side which I won't be able to handle if the modification of vector offset register takes effect right away. \$\endgroup\$
    – Ali
    Mar 3, 2016 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.