1
\$\begingroup\$

I wish to update the software running on a node having a ARM Cortex M4 MCU.

to do so, I understand I will have to run a bootloader in my TI ARM Cortex M4 development board that can receive a binary file over-the-air and program certain section of flash. I understand the functionality of receiving binary file over-the-air will have to be added to this bootloader.

This sounds all correct but I do not understand how this can be achieved. How is it possible that I program parts of the flash in the MCU by the same MCU itself?

Do I need additional hardware to do update software running on my node? All I want to do it to update the software running on my node over-the-air. A bin fine can be downloaded over HSDPA. For easy testing I can do this over Ethernet.

I would so much appreciate if someone can elaborate how this process is done in a more detailed format for me to understand the procedure. Thank you very much.

\$\endgroup\$

2 Answers 2

Reset to default
4
\$\begingroup\$

In fact it's quite easy - there are multiple methods. I outlined one in this thread.

Basically you will have two separate pieces of software running. Consider the following setup (it's just an example):

  • Bootloader (Flash address 0x0000 - 0x1000)
  • Application (Flash address 0x1000 - 0x2000)

(of course, those are dependent on your requirements)

Now, the application will download the binary (we'll call it FW 2.0). It will set some special bit in your controller and perform a reboot. Your CPU always starts at address 0x0000, it will load your bootloader. Your bootloader checks if the "special" bit is set and will then flash the binary file to address 0x1000-0x2000. It will then reset that special bit, indicating no new firmware is available. It will then reset itself again. Now, again, the bootloader starts - it will detect that the special bit is in fact NOT set and do nothing but simply perform a jump to the application (0x1000) from where the program will execute (now with the new firmware).

You might also want to include an option to run a default firmware or to load a firmware via UART in case your application cannot be written correctly or power is lost during the update.

\$\endgroup\$
5
  • \$\begingroup\$ Thank you. This clears up a lot. Although I still have couple of more questions. Lets say the Application_old downloaded the .bin file, where is it supposed to store it until bootloader loads again? Do I have to keep the bootloader previously informed where to look for a new .bin file every time the special flag is SET? \$\endgroup\$
    – Denis
    Apr 21, 2015 at 17:04
  • \$\begingroup\$ And how is it possible for me to use an MCU to edit flash of itself? I use the TI TIVA129 Arm Cortex M4. I hope performing writes to flash while the code is running is allowed. Supposing I have a binary file, does the bootloader read it byte by byte and place a copy of the bin file in the appropriate area of flash memory? Am I supposed to write for the bootloader to support that action? Thank you so much for your response \$\endgroup\$
    – Denis
    Apr 21, 2015 at 17:08
  • 1
    \$\begingroup\$ You will probably need to define a region for where to store the binary application file (you can define such a section in the linker). The other option is that it's up to your bootloader to get that file and (while receiving) store it directly at the application section. Usually, you want to keep your bootloader as simple as possible (but it may be that you require special features). \$\endgroup\$
    – Tom L.
    Apr 21, 2015 at 17:21
  • 1
    \$\begingroup\$ You will usually find some method to write to flash in the board support package or TI tools (check the TI docs, I am unfamiliar with the TIVA family). Keep in mind that you do not overwrite code that is currently running. You are overwriting code which "just sits there and waits to be executed". \$\endgroup\$
    – Tom L.
    Apr 21, 2015 at 17:23
  • \$\begingroup\$ Truly appreciate your effort Tom L. \$\endgroup\$
    – Denis
    Apr 21, 2015 at 17:58
0
\$\begingroup\$

You usually cannot write to the same page you are executing, flash is split into segments, pages and blocks, the addresses should be detailed in the data sheet for that specific processor. To get around possibly, if the processor supports, you can execute from memory. When you design your bootloader you should always take into consideration power failure scenarios, i.e. how do you know the bin was downloaded and written in its entirety to flash without any error, what if it doesn't, how do you recover.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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