Go Down

Topic: Bootload using an arduino and SD CARD (Read 2 times) previous topic - next topic

LuisSoares

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

bogdacutu

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.

bogdacutu

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

GoForSmoke

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?

I find it harder to express logic in English than in Code.
Sometimes an example says more than many times as many words.

bogdacutu

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?

:0

Grumpy_Mike

Quote
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.  :smiley-mr-green:

LuisSoares

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  

Grumpy_Mike

Quote
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.

LuisSoares

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

PaulS

Quote
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.

LuisSoares

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

pdepuydt

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

bogdacutu

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

pdepuydt

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.

LuisSoares

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

Go Up