2012-09-12 03:40 AM
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.2012-09-12 04:57 AM
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... EtaPhi2012-09-18 06:01 AM
2012-09-18 08:36 AM
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