next topic »

[Reply #15 on:]

Basically you want to be able to remotely update the software on the controller ?

[Reply #16 on:]

Yes, i want to be able to remotely update the firmware of the MCU#1.

Basically, the feature that i want to implement is, distributed (big number of remote units) remote firmware update.

[Reply #17 on:]

In that case I would opt for the hardware track, using the SPI approach.

MC1 acts as a supervisor updating the firmware as needed and controlling MC2.
MC2 acts as the slave executing the actual program.

It would allow you to
 1) implement CRC checks on the newly downloaded firmware.
 2) Keep the latest-1 version at hand, in case of an update failure you could rollback.
 3) Establish a protocol between the 2 MC's to determine the update was successful.
 4) Implement a watchdog function
 5) Send and receive notifications

And you would not need to modify the boot loader, provided it operates the same way
the USB interface does. In fact using the USB might also be an option.
 
Just a thought.

[Reply #18 on:]

Yes basically you agree with the main idea.

The problem with using the USB, is that i don´t know how the actual bootloader works and consequently i don´t know the protocol/logic it uses.

With the memory serial programing i have the exact protocol on the datasheet and i can follow it.

If someone has a document where the usual UART/USB burn method (used for the arduinos) is described i could try your approach.

Best regards

[Reply #19 on:]

And now can you give ideas on how?

Look at the source code for the bootloader. When you understand EXACTLY what it is doing, you'll know what you need to change to read the hex file from the SD card and write it to flash.

Do not expect this to be a 20 minute job.

I had a good look at section 27 of the Atmel ATmega docs... is a bootloader necessary? They have provision to not use one though that involves loss of self-programming capability and maybe makes it easier to end up with a 28-pin brick.

Even without using a bootloader it appears that knowing what/how/why the bootloader does what it does should be necessary to do the job. PaulS made a very sensible reply there.