I want to develop a board with to ATmega inside, on 2560 (The main MCU) and an acessory MCU (ATMega 644 or inferior) to burn the main .HEX present in the SDCard to the 2560.
I want to understand more of how is the code burn in to the MCU memory so i can, do the code for the acessory MCU to read the .HEX file from the SDCard and burn it into the 2560 program memory.
Where can i learn more about MCU memory program burn all process?
Mike, I have seen where the Arduino is used as an ISP to write ATtiny chips with hex files made for them. The tiny doesn't have a bootloader. The same method can be used to write 328's w/o boot loader. And it's all done with a few wires/pins.
Yes sure it can.
I thought the OP wanted to do it with one processor.
Been breathing too much glue today making up 20mm coil formers with 4mm plastic U channel.
But in the rogue circuits case, technically the bootloader is writting the code, the other acessory MCU implements most of the FAT32 and allows the bootloader to write itself using UART comunication between the 2 MCUs. It is mandatory that you burn a special bootloader to use this approach.
In the case of an arduino programing another arduino is the same case because technically is the bootloader that is fetching the code from the other arduino that is acting as a programmer...
Can you elaborate on the reason why, one MCU cannot write the all flash of another MCU Mike?
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.
There is already a guy that did that, Brett from Rogue circuits.
Apparently it is not possible to fit (Max bootloader size) all the code you need to implement the FAT32, fetch what you need from the SDCard and write it to the flash.
To solve that he arranged for another MCU (MCU#2) that implemented most of the FAT32 stack, and he was able to fit in the main MCU a custom bootloader that comunicated with the MCU#2 and fetch the code.
I was thinking of using another approach, not very distant...
Using 2 MCUs: MCU#1 (ATmega 2560) and MCU#2 (ATmega328).
MCU#2 would have the normal arduino bootloader and its only objective would be to read an .HEX file from the SDCard and execute a serial programming of the MCU#1. In this case MCU#1 wouldn´t need a bootloader, all the flash would be programmed.
What do you think of this idea?
What me the problematic points from your point of view?
I'm not sure I completely understand what you are aiming at but I assume you basically want
to be able to change the program running on the MMC by simply swapping a memory card
and resetting the MMC, in order to have it restart and load the program on the memory card.
Perhaps there is a possibility to achieve this on a software level. I am thinking along the lines
of using dynamic linking at a compiler level ? This basically postpones the hunt for the library function
until runtime instead of looking for them and linking them into a single program file at compile time.
The idea would be that the loop procedure would locate and call a 'nested' loop procedure specified in another
library. The called nested procedure could be structured into an endless loop (do while (true) {}; ).
I haven't played with the compiler options for the Arduino yet so I am not sure.
I agree with bogdacutu, basically you need to be able to read the memory space of the memory card.
Like an HD does not need to be formatted in order to be able to read sectors of of it.
The boot loader basically acts like the Bios of a pc. Only here you can not specify where to look for
the 'application' that needs to executed. That location is hardcoded into the boot loader.
So you are left with few options:
a) A hardware solution to what is basically a software issue, kinda overkill I feel.
b) A modified boot loader (not for the faint hearted), basically change the start location.
c) A program on the MMC that loads the app from the MC (Kinda like a boot loader on pc where you select the OS you want to start).
Unless the compiler is more powerful and feature rich than documented it looks assembly your only option.
Write the loader program in assembler, this allows you to use the full potential of the MMC (you'd need the instruction data sheet)
and bypass the 'higher language' and subsequent compiler limitations.
My system needs to be able to go to a remote repository (internet) of .HEX files and download the respective .HEX file.
If the system downloads this file, it means that this new .HEX has to be burned on the memory of the MCU#1.
In this case the MCU#1 issues a signal to MCU#2 that Resets MCU#1 and burns the file via serial programming.
After MCU#1 is programmed, MCU#2 pulls Reset signal high, and normal operation is resumed.
This process doesn´t seem to hard, at least from what i have read in the datasheet.
Basically this way:
you don´t have to deal with bootloader design
don´t need to deal with self programing logic which seams harder to do and debug
the serial programming process seams well documented
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
implement CRC checks on the newly downloaded firmware.
Keep the latest-1 version at hand, in case of an update failure you could rollback.
Establish a protocol between the 2 MC's to determine the update was successful.
Implement a watchdog function
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.
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.