next topic »

[on:]

Hi

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?

Regards

[Reply #1 on:]

And when you do understand more you will find that it is imposable.

Imposable?

Any way, I'm sure that I saw a bootloader that reads a HEX file from the microSD card and writes it to the flash memory.

[Reply #2 on:]

http://www.thefreedictionary.com/Imposable

You got no reason for insulting me.

No more offtopic, here's the link: http://www.roguerobotics.com/wikidocs/code/bootloader_using_ummc

[Reply #3 on:]

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.

So why can't one chip program another?

[Reply #4 on:]

Yes, you can use a board as an ISP, which can then program another.

And would it be that hard to edit that code, for what the OP needs?

 

[Reply #5 on:]

So why can't one chip program another?

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. 

[Reply #6 on:]

I´m not sure if it is impossible.

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?

regards  

[Reply #7 on:]

Can you elaborate on the reason why, one MCU cannot write the all flash of another MCU brattain?

No that was wrong sorry it can.

[Reply #8 on:]

Ok

And now can you give ideas on how?

What would be the easiest way? or best approach?

Is it hard to do the code of the MCU programming?
Basically i wanted to fetch the .Hex from the SDCard and write it to the Flash memory.

Regards

[Reply #9 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.

[Reply #10 on:]

Hi PaulS,

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?

Best regards

[Reply #11 on:]

Hi Luis,

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.

Just my 2cts.

Peter

[Reply #12 on:]

You don't need the full FAT32 filesystem function, just reading.

[Reply #13 on:]

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.

Either way the path is steep.

[Reply #14 on:]

Hi,

Let me give additional context.

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
• can maintain my SDCard with FAT 32 formatting

best regards