An easy way to do firmware updates over complex interfaces (USB, Ethernet etc)  - Page 1
Forum section: electronics / general

author: andyturk
author_rank: Frequent Contributor
timestamp: March 25, 2013, 02:04:19 am
content: Nice!ARM chips have tons of flash these days, so having space for a complete second image might not even require external hardware. Is this the right pseudo-code?Code:if (checksum_is_valid(update_image)) {copy(main_image, update_image); // copy(dst,src)if (!checksum_is_valid(main_image)) watchdog_reset();step_on(update_image); // make sure it's invalidwatchdog_reset();} else if (checksum_is_valid(main_image)) {jump_to(main_image);} else {fall_back_to_OEM_bootloader(); // UART, USB, etc.}

author: free_electron
author_rank: Super Contributor
timestamp: March 25, 2013, 03:11:46 am
content: i had a system like this :Code:@reset : the processors boots from the top FLASH page . this is where the bootloader sits. The boot address is set by hardware (this was an asic)- check first page empty -> wait for firmwareif ok, jump to 0 and runduring firmware run if an update was needed we simply wiped the first flash page.this had two advantages : we could pre-program the bootloader in top flash , seal the top flash sector and then during in-system test the board would automatically start waiting for firmware as the rest is empty.... we load test firmware , do the entire board test , tell the test software to kill the first flash page , reset , the system waits again for firmware and now the field firmware was loaded.if a software update was required we sent a command to enter in bootmode : the firmware would erase page 0 and perform a reset.. doneThe bootloader had a mechanism where it would listen for communication while it was initialising the system ( the bootloader also initialised the memory controller , paging system and some other control registers. it would test the main ram to determine its size etc. during that time it would listen for incoming connects. if a magic packet was received it would enter in update mode. so even if the firmware was hosed we could recovernote that this was not a public accessible system. these are blades in a telecom rack.the main controller would note how many times communication with a slave was lost. if this happened 4 or 5 times in a row it was assumed the firmware image was corrupted and the host would powercycle the slave and send the magic packet at boot.

author: BravoV
author_rank: Super Contributor
timestamp: March 25, 2013, 10:53:59 am
content: Thanks Mike, interesting tips especially on those external memory, something to build into when I'm dealing with 8 bit mcu project in the future.Quote from: andyturk on March 25, 2013, 02:04:19 amYeah, ARM has tons of advantages and features, like the TI ARM mcu that I ventured into recently, not sure at other ARM brands, but I guess this must be norm, fyi TI Stellaris is my 1st ARM. All those interfaces like SPI, I2C, UART, CAN, Ethernet and USB libraries are already burnt-in / included at the on-chip "ROM", so the main app will be lean and mean.Apart from huge flash memory advantage, below quoted partially from the TI Appnote on their ARM Stellaris "fancy"boot loader mechanism :Quote

author: djsb
author_rank: Super Contributor
timestamp: May 04, 2013, 11:03:11 am
content: Just watched the video. I'm still trying to understand how this works. How could I try this using a PIC16F819 programmed using the CCS C compiler (PCM). Could it be used with a simple RS232 serial link and a Microchip EEPROM as well?Once I understand how this work I might have a go with it.David.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: May 04, 2013, 11:36:11 am
content: Quote from: djsb on May 04, 2013, 11:03:11 amYes, but there would be little point - if you have simple RS232 then just use that to directly with a conventional bootloader to program the flash fro mRS232 commands. .The advantage of this method is for cases where the medium (storage device or network protocol) from which you are getting the new firmware is complex to deal with. It splits the process into tow sections- getting the new firmware into a place it can be accessed very easily (typically using code that already exists in the application), and a small and simple routine to copy the code from that place to the main flash.