cancel
Showing results for 
Search instead for 
Did you mean: 

Software Update on STM8

spveer
Associate II
Posted on September 12, 2012 at 12:40

I am working on a low density STM8S with 8Kbyte flash memory.

I need to accomodate a main software and a recovery software.

I do not need any special bootloader as I am planning to make

the software update as part of the application itself.

I am newbie in this.

Can someone tell me if the following strategy sounds good or

if it has any issues:

Divide the Flash memory into (Program memory + UBC region[user bootcode])

Program memory shall contain the main software.

UBC area shall contain the recovery software.

Recovery software shall be used in case a software update fails.

Any insights/comments will surely help me.

Thank you.

3 REPLIES 3
fggnrc2
Associate II
Posted on September 12, 2012 at 13:57

Hello pradeep.

I did what you are planning.

My application can update its firmware by loading a file from a microSD.

There are some issues to solve before obtaining a working solution.

The first one is related to interrupt handlers.

Since the interrupt handlers table is located in the UBC zone, your bootloader must provide some ''virtual'' interrupt handlers which activate the right handler or disable the corresponding interrupt source if they don't find an handler.

Another issue is flash programming which should be done by blocks of 128 bytes each for speed reason. This task must be executed from RAM, so you must pay attention to copy some bootloader code to RAM and execute it from there.

This architecture increases the flash use because UBC size con grow by chunks of 64 (low density devices) or 512 (high density devices) bytes.

The ''virtual'' interrupt handlers, its re-routing table, the code which updates flash and its execution from RAM grow also flash use, so I advice you to plan carefully your application because it's easy to run out of resources...

EtaPhi

spveer
Associate II
Posted on September 18, 2012 at 15:01

Hi Etaphi,

Thank you for the reply.

Your answer gave me some confidence to keep going in that direction.

I am right now confused about the linker settings.

I have 8KB. 0x8000 to 0x9fff

Further I have bootloader + application firmware.

Should I keep the bootloader+application firmware in one stvd project?

The bootloader has to be written once into the UBC region using ICP and I can forget about it.

Later I need to update only the application firmware using IAP.

How can I setup my project so that I have two different binaries:

one which includes (bootloader+application firmware) for ICP,

and second which includes only the (application firmware) for IAP?

Thank you for some more insight.

fggnrc2
Associate II
Posted on September 18, 2012 at 17:36

Hello pradeep!

My application consists in one STVD project and makes a clever use of linker segments.

It's compiled with the STM8 assembler toolchain, but you can replicate its structure with any toolchain, once you know how to assign a variable or some code to a segment.

Your microcontroller address space is probably arranged as follows:

ram0: from 0x00 to 0xFF

ram1: from 0x100 to 0x1FF

stack: from 0x200 to 0x3FF

eeprom: from 0x4000 to 0x407F

interrupts: from 0x8000 to 0x807F

code: from 0x8080 to 0x9FFF

If you use a C compiler, it probably manages ram0 and ram1 segments for you, so you don't have to mind of them.

The stack segment is usually reserved for local data, interrupts and function calls.

The interrupt segment is the first interesting segment, because it stores the interrupt handlers addresses. Your UBC must start in this segment.

Then, you must split the ''code'' segment by defining two new segments.

Your bootloader must occupy the first segment (e.g. ''boot''), which is the one that starts at 0x8080, because it must be write-protected when the application firmware is updated.

In low-density devices, this segment must made of 64 bytes blocks.

You must assign your interrupt vectors and function pointers to the second segment (e.g. ''interface'').

If your application runs out of code segment, this segment may be allocated in the eeprom to save some bytes for your application code.

The code segment takes all left bytes.

From a programming point of view, your bootloader is alike a libray which is included in a project (once it's fully developed and debugged).

To build an application firmware image, you have to compile your sources and extract the contents of the ''interface'' and ''code'' segments from the .s19 file (I use the srecord tool to do this) and release it to manufacturing.

BTW: you don't need to do this while you are developing the application firmware because your IDE takes care of updating the flash for you.

I hope you'll find this useful.

Regards,

EtaPhi