2
\$\begingroup\$

I am currently using ST32L152RE controller interfaced with BLE CC2640R2F module and 4 MB external flash memory interfaced through spi. I was trying to upgrade the firmware of my st controller using BLE. My approach is to receive firmware using BLE and store it in flash memory, then ask controller to restart and execute the code written in flash memory.

As far as I think there are two possible ways.

  1. I need to copy that code file (binary data) from external flash memory to controller flash memory then reset the controller so that it execute the code written in internal flash.
  2. I will ask the controller to directly execute the binary file or code file from external flash memory. (I have no idea if this will work or not)

I am taking an assumption of possible ways to get the results. Very confused if any of this approach works or not.

Improve this question
\$\endgroup\$
  • \$\begingroup\$ Why do you even need the external flash memory? It is just an error source that increases complexity and costs extra money. Just write a bootloader and use on-chip memory. \$\endgroup\$ – Lundin Mar 27 '19 at 14:13
  • 2
    \$\begingroup\$ The obvious reason not to do that is that once you start overwriting the program you can't recover to normal operation if the transfer breaks before completion. To avoid that you need an A/B scheme in internal storage if there is room, or else staging the new version externally until it is fully received and verified. \$\endgroup\$ – Chris Stratton Mar 27 '19 at 14:17
  • \$\begingroup\$ you need to use a part that has flash that can be accessed while running from it, they will for example have two or more banks you can run from one and modify the other. A/B as mentioned but need chip support, check on that. the alternative is to trampoline off the flash and run an ideally small program in ram that reprograms the flash. also remember that the flashes are generally larger than rams so you have to 1) have space for al lthe code you are running and 2) have space for the new download in ram, then program to flash or 3) try to program to flash during \$\endgroup\$ – old_timer Mar 27 '19 at 18:07
  • \$\begingroup\$ the download an A/B thing. \$\endgroup\$ – old_timer Mar 27 '19 at 18:07
  • \$\begingroup\$ @Lundin External Flash is needed to store data from received from BLE. As new code will be transferred to the board using BLE only. I don't think its a good idea to directly write received from BLE to the chip, as chip will be busy in some other work or data might get corrupted during reception over BLE. So what I think is stored the data first in Flash Memory then check CRC error then for further with copying data from external flash to internal flash. Also we are using external memory for our device data storage also. \$\endgroup\$ – Vaibhav Mar 28 '19 at 5:21
3
\$\begingroup\$

If you are using less than 50% of your internal flash (and the new SW is also < 50%) then you could load the new software into the upper part of that memory, test it runs and then copy into the lower half once you're happy.

You would need some sort of bootloader to do this however, I'm sure there are plenty of STM32 guides on how to do this. Your approach of using the external flash memory is fine too, and would allow you to perform a CRC on the new SW image data once it has been transferred over before copying it into your internal flash. I'm not sure if the STM32 will allow you to execute code from the external flash though.

A bootloader is usually a small section of the internal flash which is written to handle all this, but this code needs to be well tested as you can usually only update it back at base (physical connection to a programmer) and not usually OTA.

Guide here

STM guide: STM

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ I had never worked on boot loader till. Will start working on this. \$\endgroup\$ – Vaibhav Mar 28 '19 at 5:34
  • \$\begingroup\$ You should get some error checking for free via the BLE protocol, if you're using the serial port profile for example, but it would definitely be worth running your own error checking algorithm too \$\endgroup\$ – mr_Alex_Nok_ Mar 28 '19 at 9:13
  • \$\begingroup\$ If you have space in your external flash you can always store a copy of the current working program (from internal flash) there to revert back to if there is problem in your new SW image.This kind of thing is quite fun to do but make sure you exhaustively test it as you don't want issues out in the field \$\endgroup\$ – mr_Alex_Nok_ Mar 28 '19 at 9:15
0
\$\begingroup\$

I assume you meant STM32L152RE not ST32L152RE, as soon as we mentioned it you should have seen from the ST website and/or the datasheet that this is a dual banked flash device. The reference manual will guide you as to how to use that. You are a LONG way from doing this through the BLE start without. You need to

understand how the chip boots and be able to control it.

write code that runs on the chip that can erase and write either bank.

come up with an A/B solution so that you can download new firmware (however you choose to do that) and be able to run it but also not brick the system. The hardware may or may not help you on this, having dual banks is one thing but does the hardware provide a way to have either bank be bootable in a non-volatile way? Or is the lower bank always what the chip boots applications off of and the other bank is just there in a way that you can use it but cant boot off of it? An ideal A/B solution is that you currently are booting off of B using B download and program A then the last thing you do is flip the non-volatile switch (set some bits in some register that hardware has provided to control this) to boot from A. and vice versa for the next download. An alternate solution that can work for more chips is, it always boots from the lower part of flash, but the first part of your boot code checks some upper area, be it a CRC or checksum or other validation of your choice, if the validation passes then you branch to that code. The real firmware living up there, when an update needs to happen you need to trampoline out of the way you need to either run the code to program the upper flash from the lower flash, the library/function/routine is not in the flash or area being erased (need hardware (silicon) that supports erasing/writing flash while running from it) or trampoline from sram, copy the routine to sram branch to sram so that you are not executing from flash then write over the upper space with the new firmware. If there is ever a problem in this process then the lower portion of the flash contains a from the factory version or at least recovery firmware that is sufficient enough to allow another try at loading new firmware. There are a number of ways to do this, you can do an A/B thing with a flash that is not dual banked but you have to have a scheme be it magic numbers, incrementing numbers, or the first part of A always has to get changed, some scheme that makes sense to have one copy that works and one copy that is being updated and if the download or update fails (power is removed in the middle of the process) it wont easily brick the system, all systems are brickable, just dont make it really easy.

you then need to learn all you need to know about this BLE device and how to communicate through it, design the protocols for your normal application including the how to update the device. this could be an alternate boot, user has to hold a button while pressing the reset to put it into update mode or not at any time the user can start a firmware update. of course there are two sides to a bluetooth connection, you either need to write the software for the other side (whats the point of making this product anyway but not to do something over bluetooth) or perhaps the protocol you are supporting has this designed in. and then marry that with your solution for updating firmware.

Assume you will fail the first several design attempts. If you hit a home run and get this design perfect on the first try, post your resume, one of us will hire you. Start slow and simple, take each research project separately not one big project that evolves but one project for learning how to program the flash one for learning how to trampoline and program the flash, one for basic BLE communications, one for working on your BLE protocol and so on. Expect failure and get back up on that horse and try it again or a different way.

Its nice to have a big project goal, but you wont make it if you cant break the big project into its smaller projects and attack those. How do you eat an elephant? One bite at a time, just like anything else. Cant swallow it whole. The fact that you asked this question means you are not yet at the point of being able to just start a project and bang through these things or cut and paste from prior projects and do it in one go. The first time you build a house you have to buy and learn how to use each individual tool, the Nth time you build a house you have the tools and know how to use them and can go forward without thinking about it too much. Each new chip or brand will provide new challenges, you may spend 5 years making STM32 based products that work great with your solution but switch to atmel or nxp and may have to start over.

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ your are right about partition the project into modules, it will be easier for me to as well to achieve results. I know i will fail many times also but i am okay with it, as you can't achieve anything in on go, there is time that you had spend on that module. Secondly, i am able to store new SW in external flash using BLE. BLE also has other application in my project. I am very familiar with the logic i need to follow, but i have no idea with its implementation, that's why i am seeking for help so that i get the idea of implementation. \$\endgroup\$ – Vaibhav Mar 29 '19 at 12:19

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.