Self Program Memory - Page 1
Forum section: electronics / general

author: tomshirvo
author_rank: Regular Contributor
timestamp: July 23, 2014, 06:46:39 am
content: Hi All,I am really interested in Self Program Memory on the Arduino Due uC AT91SAM3X8E.I have been looking around for information but can't seem to find any useful stuff or my searching isn't for the correct thing.Just wondering if anyone has done this before and if they could point me to the right track so I can start learning how to do this.I have been building a lot of things with the Arduino platform and using Arduino Due for most of them as my projects require more then the Uno can offer.One of my projects has multiple hand held devices communicating to a central server. I keep having new ideas, I also find bugs that need fixed. It would be great to be able to roll out new software updates through the wireless that I have in the devices.Anyone with any information or a good place to start would be very much appreciated.Thanks in Advance

author: rob77
author_rank: Super Contributor
timestamp: July 23, 2014, 08:43:12 am
content: self programming memory is just a plain writing to the program flash done from the program itself.look at the datasheet for details (timing, etc... ) btw.. it's incredibly slow compared to SRAM.but in general1. have a block of flash empty for potential FW upgrades2. in the bootloader you need to have a code which is moving that block to it's final position in the program flash (if there is something in the reserved "upgrade" block) and then passes the control to the main program3. in your main program you need to have a code which will receive the upgrade, write it to the "upgrade" block and either trigger a reset or passes the control to the loader.

author: mikerj
author_rank: Super Contributor
timestamp: July 23, 2014, 11:46:57 am
content: Since it's an ARM Cortex based micro, you also have the option of running bootloader code straight from RAM (having copied it from a reserved/write protected area of flash) so you can directly overwrite the existing code in flash.

author: Berni
author_rank: Super Contributor
timestamp: July 27, 2014, 07:12:08 am
content: Only thing you have to watch out for is that you don't overwrite the firmware update code during a update. Yes this can be done by copying code to ram, but best thing to do is to have a boot loader at the reset vector that always runs at power on and sits on an area of flash that it knows to never try writing too even if you tel it to. That way you can never brick it and you simply need to tell the compiler for the actual application code to not use that memory area.If you do a destructive flash update you would want to at least first save it in to ram so you can crc check it and not permanently write a damaged image, but you can still feed it a flash image version with a broken update feature and brick it that way.

author: mikerj
author_rank: Super Contributor
timestamp: July 28, 2014, 07:19:51 pm
content: Quote from: Berni on July 27, 2014, 07:12:08 amThe bootloader always has to reside in a protected area of flash, even if you ultimately run it from RAM. One advantage of running it from RAM on most Cortex M parts is that you don't suffer the lengthy program memory bus stall when you perform a page erase, which can be quite important for some applications. Some devices now have dual banked memory so you can run from one bank whilst writing to the other and not suffer bus stalls.For an serious applications I would always recommend incorporating an embedded CRC and program length word within the binary image, which should be checked by the bootloader when the module is powered on.