STM32 F407VG Boot into different (main-)applications - c

For a project I just started working on, I need to write a firmware in C that lets me boot into two different firmware versions. The task is to be able to update a device which includes an STM in the field using the RS485 Port with an Intel .hex file. My idea was to place the two firmware versions at designated starting addresses in the flash, including some kind of checksum for data integrity. According to the flash module organization found in the reference manual, my first thought was to place one version into sector 10 (starting at 0x080C0000) and the other version into sector 11 (starting at 0x080E0000). After every reset, the STM32 should boot into a "bootmanager" which is just minimum code that decides, whether the firmware in sector 10 or sector 11 is the newer version. I want to clarify my idea in the following graphic:
[Rough process][1]
[1]: https://i.stack.imgur.com/xLowh.png
The 128kBytes of every sector are sufficient. So far, I was able to write Single Bytes into the Flash and read them afterwards. Also, I have already set up a working UART communication using the RS485.
My questions
Can I just write the .hex file into the Flash as it is without modification like
:020000040800F2
:1000000002200B
etc?
As I am unexperienced with with jumps: How should I perform the jump from the "bootmanager" into sector 5 firmware? Are the adresses automatically relative to the entry point in sector 5?
Can you give me keywords or tell me, what challenges I will encounter?
*EDIT: I'm aware that the STM itself contains a bootloader. Unluckily, the RS485 device is hardwired to the GPIO pins used by USART2. According to the reference manual, the internal bootloader can only be used by USART1 and USART3, CAN2 and USB OTG FS

Can I just write the .hex file into the Flash as it is without
modification like
no you cant. You need to modify the linker script to archive it
You need to have the whole both applications in the FLASH so divide it 50/50%.
I usually add some serial FLASH to have a copy of the firmware if both of the images are damaged.
Yuo need to write the custom bootloader.

Most of the STM32 microcontrollers have support for dual memory bank and on the fly update (cf AN4767 - On-the-fly firmware update for dual bank STM32 microcontrollers)
This will allow to perform exactly what you require.
Usually the microcontroller will need to have a bootloader and 2 banks for the image.
When booting the bootloader will start and check which version it would have to boot and set the start address accordinngly.
This application note is for the F7 series but you can check it to see how it could work for your specific microcontroller (cf AN4826 - STM32F7 Series Flash memory dual bank mode).
Regarding your questions:
The code would be written as usual but twice (or 2 different firmwares)
Look into the application notes referenced and keywords such as: dual bank, on-the-fly update, DFU, etc

Related

Is it possible to write Cert.der and key.der in internal flash EEprom at run time? I am using stm32

All I am trying to write certifictae and key to flash EEPROM of stm32 , I know we can write the string but is it possible to write whole certificate(.der) in flash. I am using stm32f7 microcontroller and using internal eeprom. and I want to add certificate and key at run time. I can write a simple Json object to the node and it works fine but i have no idea if i can write a cert.der/key.der in the Mcu.
ST offer an HAL library for manage the R/W on EEPROM. If you want to use this tool, you can found all details on project link X-CUBE-EEPROM and EEPROM emulation techniques and software for STM32L4 and STM32L4+ Series microcontrollers.
If you prefer to write yourself the R/W functions, you can found a good start point at ST community forum: EEPROM read/write.
A little note: when you try to find some reference about STM32 EEPROM
inside MCU package, many, many, many time you can found for STM32L*
family. Don't worry, the porting to another MCU is very easy.

Linux - How to upload code to a dedicated freescale chip NIC on my motherboard?

I have bought a Gigabyte g1.guerilla motherboard and the NIC is a dedicated freescale chip on the motherboard. It is connected to the PCI bus.
I am running Linux and unfortunately there is no driver for it. I am working to write one, however I am hitting a basic problem: How to communicate and upload code to its dedicated CPU-RAM?
Much help appreciated.
I am running on ubuntu and the chip is a mpc8308vmagd PowerQuicc II pro
I don't know anything about your specific motherboard or the processor, but are you totally sure you need to upload any code to the processor?
Usually, if a peripheral needs any code (firmware), it's already present on a ROM or a flash chip and you only need to touch it if you specifically want to write your own firmware for it. AFAIK the way it usually works is that the peripheral exposes a set of registers on the PCI bus and you interact with it by poking the registers (usually with MMIO). That is, you don't write code for the peripheral, but you write a kernel driver that pokes the registers (ie. the API for the peripheral) when it wants the device to do something.
Now, in general the register descriptions aren't often freely available, which can make writing drivers really hard.
If you really want/need to write your own firmware for the thing, it probably depends on where the code is stored. If it sits in ROM or in an inaccessible flash, you'll probably need to do some soldering. If the firmware is updatable, I'd probably try to reverse-engineer the software they provide for updating the firmware, if one is available. (Unless it allows uploading arbitrary files already, of course)

Can I initialise and use USB-CDC purely in RAM?

The chip is an Energy Micro EFM32380f1024 ARM microcontroller and I am using IAR ARM Embedded Workbench. I am aware of the __ramfunc directive however accomplishing initialising and accessing USB completely in RAM (as the flash is going to be completely erased) requires all USB libraries that will be used to be placed in RAM?
This will be used to upgrade the firmware on the microcontroller hence the flash erase. The USB is initialised and used (for normal use by the firmware) for serial communications. I do not wish to use the bootloader for firmware upgrades.
as the flash is going to be completely erased
Not a good idea. In case the update process fails to write the new program completely and the power is lost, your device will be bricked.
Using a bootloader is strongly recommended when you want the flash to be updatable by a user.

Persist data with ARM MCU in c

I am relatively new to embedded programming and have not been able to find a way to save data to the MCU, so that it persists during reboots.
I have read somewhere that I will need to use PROGMEM to save to the MCU flash. But have not found any further details.
I need to be able to perform the following:-
Save a string (device name) to the MCU.
Retrieve the string (device name) from the MCU when required.
I am developing on a ARM Cortex M4 Microcontroller
EDIT: I have just noticed that the ARM Cortex M4 (TI TM4C123x Series) I am working with has 2k of EEPROM, so I am assuming that is a better option for persisting data. But how?
If the data needs to persist through only a soft reset then you should be able to store the data in RAM. You would need to make sure that the startup code does not initialize the portion of RAM where the persistent data is located. But if you want the data to be persistent while power is removed then you need to store the data in non-volatile memory such as flash or EEPROM.
In order to write data to flash or EEPROM you're going to need driver code that manipulates the control registers as necessary. In order to write the driver you're going to have to read and understand the relevant sections of the data sheet for the device.
TI makes an evaluation board called the Tiva C LaunchPad (EK-TM4C123GXL) which contains a TM4C123G microcontroller. In support of the board they also provide software including example programs and drivers. Their driver software includes example drivers for the on-chip flash and EEPROM. You should download this software and review the flash and EEPROM drivers and other examples. You may be able to use their example driver as-is. Here is a link to the Tiva C LaunchPad resource page where you can download the software.
You need to look at the data sheet for your specific microcontroller or system-on-a-chip.
You can probably write to program flash, but that's a bit "scary" since then you run the risk of external tools overwriting your data for instance when you re-flash the actual software the next time.
If your device has some other non-volatile storage area, use that instead of the program flash.
The exact directions on how to do this are (way) outside of what the C language specifies; you need to figure out which registers to write to and in what exact sequence. Often there are timing requirements too.

Is bootloader required to run a firmware?

I am currently working on firmware for a Stellaris ARM microcontroller board and I am running the SYS/BIOS RTOS.
I was wondering if the bootloader is required on the board when I upload my firmware onto it. Can I overwrite the bootloader on the flash with my .bin file, or am I required to offset my start address to preserve the bootloader.
In the general case (i.e. not specific to Stellaris), software is software, the bootloader is software, your application is software, the processor cannot tell the difference so quite evidently a bootloader is not required, the software that runs at reset could as easily be your software.
However the obvious benefit of a bootloader is the ability to apply in-field updates without connecting special equipment; you might regret loosing that capability.
Some chips (again generally, check your data sheet for Stelaris specifics) have a bootloader in mask ROM rather than Flash and you cannot delete or overwrite that, but usually configuration pins can be set to select the boot behaviour in order to by-pass the bootloader for example.
No you can use jtag and dont need running software in order to stop and re-flash the firmware.

Resources