Field updating of STM32 with data in external qspi flash

[imtiaz]

Posted on July 05, 2017 at 02:51

Hi All,

We are using an STM32F7 processor.

We have a typical application that will store LCD images and other asset type data in qspi flash. The QSPI flash will be memory mapped. We also have external memory mapped RAM.

In the code the images will be specified to go into the external qspi flash section , I guess using a scatter file definition of memory regions and &sharppragma in the code.

Could anyone give me some direction as to how we could update this software in the field - where we are not only updating the internal 2Mb flash , but also the external qspi flash. Currently I am using the ST system bootloader to update the internal flash.

I am assuming that a customised bootloader will be needed based on the address of the data , internal flash starting at 0x08000000 and external 0x90000000   it will have two different API's to write to either internal or external memory.

Does that mean that I will need to work with a hex file rather than a binary?

The setup of our hardware is very similar to ST's F769 eval and discovery boards. However these are programmed using dedicated programming interfaces like swd/jtag and stlink etc which have customised loaders.

In our case we will be doing OTA updates.

Highly appreciate pointer in the right direction.

Best Regards

Imtiaz 

#qspi-flash-memory-mapped-bootload-stm32f7

[Jeroen3]

Posted on July 10, 2017 at 07:37

Sure. But 'split hex into binaries' is more than one operation. It took me a while to the hang of it.

First, call srec like this:

http://srecord.sourceforge.net/man/man1/srec_input.html

.exe @arguments.srec

And in those argument files, you put the commands. With comments starting with #.

http://srecord.sourceforge.net/man/man1/srec_examples.html#CROPPING THE DATA

of the file. Do this twice, for each region you want.

.\build\srec\input.hex # Take this file
-intel
-crop 0x08000000 0x0803E800 # Extract this region
-o .\build\srec\output.hex # Store it here
-intel
--obs=16�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Convert to

http://srecord.sourceforge.net/man/man1/srec_examples.html#BINARY FILES

:

.\build\srec\output.hex 
-intel
-fill 0xFF 0x08000000 0x0803E800 
-offset - 0x08000000
-o output.bin
-Binary�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Other examples:

If you want to add a checksum to a file, you can. This adds STM32F103 hardware checksum to 2_program.hex at location0x0803E7FC.

But you have to

http://srecord.sourceforge.net/man/man1/srec_examples.html#FILLING THE BLANKS

first.

�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?.\build\source.hex #input file name
-Intel #read input file in intel hex format
-fill 0xFF 0x08000000 0x0803F000 #fill gaps from with value 0xFF
-Output_Block_Size=16 #generate hex records with 16 byte (default 32 byte)
-address-length=4 #generate extended adress records type 04
-o .\build\srec\output.hex #output file name
-Intel #generate intel hex output file�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Crc:

.\build\srec\input.hex 
-intel 
-crop 0x08000000 0x0803E7FC
-STM32 0x0803E7FC
-o .\build\srec\output.hex 
-intel 
--obs=16
�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

You can even merge the two hex files. Optionally later -unfill to optimize the size.

.\build\srec\file1.hex 
-intel
.\build\srec\file2.hex 
-intel
-o .\build\srec\file1_and_file2.hex 
-intel�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

[imtiaz]

Posted on July 11, 2017 at 00:20

excellent - thank you - I will give it a go

[Tesla DeLorean]

Posted on July 11, 2017 at 03:17

Here we create a binary package file, a bit like a .ZIP or .DFU file, in a form that describes the data and provides integrity checking. If appropriate we'll compress and encrypt the data. Simple tools will take the .AXF/ELF files as input, or .HEX depending on what makes the most sense.

The project builds in the normal way, so no special scatter file or linker script. A post link step take the object file output and translates to the deliverable image. The firmware, or loader, determines where this data is parked (ie High Flash, QSPI, MicroSD), and the update process blanks the areas of flash it needs and writes the new content, if the integrity of the flashed application is good we execute it, otherwise it stays in the boot loader, so we don't brick our devices. The integrity checking is multi-layered so the checks and signing added by the image generation process means it's not going to start the process with a bogus image. Failure therefore points more to errors introduced by the developer/compiler, or a physical failure of the flash sub-system.

[imtiaz]

Posted on July 11, 2017 at 03:31

Hi Clive,

In that case , how would you specify while writing the code the location of your data. Example if you had images or fonts etc that were too large for your internal flash?

Thanks

Imtiaz 

[Tesla DeLorean]

Posted on July 11, 2017 at 04:04

You'd just build your project as if you were flashing it directly from Keil, or whatever.

You'd take the output .HEX, or .ELF, and create, for example a .DFU file (see UM0391 for format specification). I've build a loader here for our micro-python implementation that reads the .DFU off a microSD card and writes it into memory, you'd need code that knows where internal FLASH is, and how to write into it, and similar routines for QSPI. But you could basically park the image in whatever linear memory have available, the image is 'address-less', its like a file, just a stream of data, with random access.

The .DFU can describe multiple memory regions, can break those regions into multiple blocks, and has a CRC over the entire image.

I'll link to UM0391 in another post so this doesn't get stuck in moderation.  

The .DFU is a simplified object file format, it strips a lot of symbols, debug, relocation, and other junk that is in the .AXF/.ELF object.

Take the .DFU file an zip it, this will give you some idea if compression would help, or not.

[Tesla DeLorean]

Posted on July 11, 2017 at 04:07

https://drive.google.com/open?id=0B7OY5pub_GfIR2ZBcDk3UXNjdzg

 

[AVI-crak]

Posted on July 11, 2017 at 06:36

Arm-none-eabi-objcopy -O binary -j .section_name filename.elf sw.bin

Collect the binary file for external memory from the firmware image file, using the section name as the target. The image file '* .elf' contains a lot of additional information intended for debugging, linear space is segmented. A binary file has a linear space, does not contain anything superfluous. It is intended for absolutely stupid programmers, like CH

When you need active protection and the ability to update the user - everything else should already work. Otherwise, the project will not end. Separate compilation allows you to complete the project quickly.

I found the shortest version of the demonstration, it is suitable for an example.

• list.h

  2

________________ Attachments : list.h.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyZa&d=%2Fa%2F0X0000000b9i%2FAGfpaw3_i.SL.SC4dSwYo_20ewXL_UV.q6zeXvqzfdc&asPdf=false