I've been trying to test a flash update algorithm that uses the Memory Mirror Function. My background is, I've used Hew with the Renesas H8 family for more than 10 years. My firmware group is new to ARM, ThreadX, and the Eclipse development environment, so we are in a serious learning curve.
As a starting point, I used Richard Warner's example project, as well as Fatih Peksenar's example project. Warner's project demonstrates the use of MMF; Fatih's project demonstrates how to burn an image from a "storage" location somewhere in ROM, to an "execution" location elsewhere in ROM, without using MMF.
I have an objective in mind, and would appreciate any comments:
- The code flash area is divided basically into three parts: a bootloader (HAL only) and two application images using ThreadX. The application images are built and linked to run in the Memory Mirror space at 0x02000000, but are stored at other addresses in code flash.
- For my initial test I'm using the S3A7 board. I set aside 32KB for the bootloader, which loads at address 0, and assigned 0x8000 as the storage location for Application1, and 0x84000 as the storage location for Application2.
- The bootloader would only execute on cold starts. There must always be at least one valid application image, and the bootloader would use some simple algorithm to determine which image to assign to MMF to execute.
- During operation, the flash thread in the running image would perform erase and burn on the 'other' application area as a background operation, with the new code coming in most likely over UART.
- Once the 'other' application is verified, the running application would use MMF to execute that image. (This raises the question: what happens when MMF switches to the other application when called from a running thread? It seems to me that this is basically calling tx_thread_enter() from a running thread. Is ThreadX well behaved in this situation?)
I thought the simplest way to verify the feasibility would be to build three projects: bootloader, Application1, and Application2; build the application images to run at the MMF address; and use the bootloader debug settings to load all three projects in ROM at the same time. From there I could test MMF function in the bootloader code. In other words, bypass the erase and burn steps for the first test and just start with two code images in the code flash and jump between them using MMF.
I ran into a strange problem when editing the debug settings for the bootloader. I tried to imitate what Fatih did when he located his ELF files in the ROM. I was able to locate ELF1 (Application1) at 0x8000 and ELF2 (Application2) at 0x84000, loading symbols only. The project started up fine and I verified the two ELFs were at the specified addresses, using the Memory tab in e2.
The problem is, I've been unable to reproduce that result except for the very first time. Checking memory addresses 0x8000 and 0x84000 shows the correct data at 84000 but something else at 8000.
Thanks for your patience in working through the long post. Comments appreciated.
tom