Hi,
I´am digging though the Optiloader code so i can adapt it to program ATmega2560 to.
Does anyone with experience think the task will be to hard?
What are the main problems or alterations that i should be expecting to do?
regards
Yeah, it will be hard. optiLoader is based on ArduinoISP, which uses the STK500v1 protocol, which doesn't specifically handle targets with more than 128kbytes of memory...
At the moment i´m trying to test the optiloader in an Atmel328 that i have in a custom board, using an arduino UNO.
And i´m receiving this answer:
OptiLoader Bootstrap programmer.
2011 by Bill Westfield (WestfW)Target power on! ...
Starting Program Mode - Failed, result = 0x0Target power OFF!
Type 'G' or hit RESET for next chip
OptiLoader Bootstrap programmer.
2011 by Bill Westfield (WestfW)Target power on! ...
Starting Program Mode - Failed, result = 0x0Target power OFF!
Type 'G' or hit RESET for next chip
Do you have any idea of what i might be doing wrong.
When i use my AVRisp to program a normal arduino bootloader, i have no problem.
Best regards
Relatively to your previous answer of difficulty of modification...
Is it that hard, isn´t it basically allowing it to write a bigger memory.
Repeating the process but for a bigger address range.
To explain a little bit more the objective...
My basic idea is to use the optiloader as inspiration to write a program that goes to an SDCARD to get a sketch (Intel.hex file) and writes it the flash memory of a ATmega2560.
Best regards
I guess since it doesn't actually implement the stk protocol, it wouldn't be THAT awful. There are a lot of things passed around in 16bit pointers that would have to be changed to use longs.
Have you seen Adafruit's modification? I think they fixed the size restrictions, for example.
Starting Program Mode - Failed, result = 0x0
This would tend to mean that there was no response to the initial SPI "start programming" command, which is usually caused by a wiring error (MOSI and MISO swapped, SCK not in the right place, etc.)
westfw:
Have you seen Adafruit's modification? I think they fixed the size restrictions, for example.
Naw. Looks like it uses 16 bit addresses as well... uint16_t pageaddr
Hei,
There was an error on the pins placement, right now it seems to be programming.
I haven´t yet run trough the code, but i read the page Manufacturing tools - stand-alone AVR ISP programmer.
There i found this comment:
Unlike the specialized Optiloader, this program can be adapted to any AVR and any size HEX file as long as you can fit the HEX into the flash of the microcontroller. Since HEX files are ascii, they basically 2x the size of the code itself. So if you have a 500 byte program, the HEX will be 1K. The sketch itself takes about 10KB so you have approximately 20KB left for the HEX which is good for about 10KB of flash to burn. This isn't tons but I suppose if you wanted to port the program to the Mega then you could fit up to 128KB of flash for massive chips.
You can paste your new HEX into images.cpp . You'll need also to set the bottom two bytes of the signature (third entry), and the fuses you want to set before you start programming, and the fuses you want to set after programming (in case the lock bits have changed). The fuse mask is used because not all fuse bits are used so if you write a zero to an unused bit (as avrdude prefers to do) it may be read back as a 1 which can cause verification errors. Next is the size of the chip flash in bytes and the size of a flash page for the chip (you may need to research the datasheet for this number). The first two arguments (name of flash and name of chip) are for your records, they arent really used by the program itself.
After you've adjusted those, go back to the main pde sketch and update
byte pageBuffer[128]; /* One page of flash */
so that the size of the flash page buffer is larger if necessary
......
Do you think that the adaloader might be a better starting point to attain my objective?
Hi,
Strangely,
i can compile and upload the optiloader sketch.
but, in the case of the Adaloader project i can only compile, when i try to upload, it gives me this error message:
Binary sketch size: 28688 bytes (of a 32256 byte maximum)
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
avrdude: failed to write flash memory, rc=-4
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51
Does anyone has any idea of what might be the problem? I´m using Arduino UNO.
Are you able to upload smaller programs?
If you have the original optiboot bootloader, it has a bug that prevents loading sketches longer than 28672 bytes.
Yes i can upload smaller sketches.
I´m using the normal arduino booloader in the AT328P to upload both sketches: optiloader and adaloader.
LuisSoares:
I´am digging though the Optiloader code so i can adapt it to program ATmega2560 to.Does anyone with experience think the task will be to hard?
I think it should be easy, based on the work I did making a sketch that reads in the flash memory:
The relevant part in my implementation was this function that reads from flash:
byte readFlash (unsigned long addr)
{
// set the extended (most significant) address byte if necessary
byte MSB = (addr >> 16) & 0xFF;
if (MSB != lastAddressMSB)
{
program (loadExtendedAddressByte, 0, MSB);
lastAddressMSB = MSB;
} // end if different MSB
byte high = (addr & 1) ? 0x08 : 0; // set if high byte wanted
addr >>= 1; // turn into word address
return program (readProgramMemory | high, highByte (addr), lowByte (addr));
} // end of readFlash
The first few lines switch the "extended address byte" which controls which part of memory you are addressing.
Furthermore the relevant line in the .hex file is here:
:020000023000CC
It is an "02" record which is an "Extended Segment Address Record". This sets the high-order byte of the address to 03 (shifted 4 bits left according to Wikipedia).
So in the next line:
:10E000000D94F6F20D941FF30D941FF30D941FF36E
The address E000 therefore becomes 3E000.
So I suggest that when reading the bootloader, if you hit the "02" record (first line) and change the extended address byte, the rest will just follow automatically.
Ah, you might need to change this part:
* We assume that the image does not exceed the 512 bytes that we have
* allowed for it to have. that would be bad.
Some of those bootloaders are 8192 bytes. Still I don't see why you can't program a byte at a time.
Optiloader currently reads the entire bootloader image (512bytes) into RAM (from .hex format in flash.)
This won't be possible with an 8192 byte image. I think this is one of the things that has been improved in the Adafruit version, though. Since there is a worse than 2:1 size difference between hex and binary, it may even be difficult to fit the 8192 byte image in flash (on a 32kbyte part) at all.
Inspired by your loader westfw, I believe I have managed to make one that will program the Mega2560. Here is a sample of it in action:
Atmega chip programmer.
Written by Nick Gammon.
Entered programming mode OK.
Signature = 1E 98 01
Processor = ATmega2560
Flash memory size = 262144
LFuse = FF
HFuse = D8
EFuse = FD
Lock byte = CF
Bootloader address = 0x3E000
Bootloader length = 8192 bytes.
Type 'G' to program the chip with the bootloader ...
Erasing chip ...
Writing bootloader ...
Committing page starting at 0x3E000
Committing page starting at 0x3E100
Committing page starting at 0x3E200
Committing page starting at 0x3E300
Committing page starting at 0x3E400
Committing page starting at 0x3E500
Committing page starting at 0x3E600
Committing page starting at 0x3E700
Committing page starting at 0x3E800
Committing page starting at 0x3E900
Committing page starting at 0x3EA00
Committing page starting at 0x3EB00
Committing page starting at 0x3EC00
Committing page starting at 0x3ED00
Committing page starting at 0x3EE00
Committing page starting at 0x3EF00
Committing page starting at 0x3F000
Committing page starting at 0x3F100
Committing page starting at 0x3F200
Committing page starting at 0x3F300
Committing page starting at 0x3F400
Committing page starting at 0x3F500
Committing page starting at 0x3F600
Committing page starting at 0x3F700
Committing page starting at 0x3F800
Committing page starting at 0x3F900
Committing page starting at 0x3FA00
Committing page starting at 0x3FB00
Committing page starting at 0x3FC00
Committing page starting at 0x3FD00
Committing page starting at 0x3FE00
Committing page starting at 0x3FF00
Written.
Verifying ...
No errors found.
Writing fuses ...
LFuse = FF
HFuse = D8
EFuse = FD
Lock byte = CF
Done.
Type 'C' when ready to continue with another chip ...
Time taken: 3 seconds.
This was running on a Uno, connected up like this:
The sketch fitted into memory fine:
Binary sketch size: 17112 bytes (of a 32256 byte maximum)
It includes the Optiboot for the 168, 328 and 2560 in the one sketch.
It might need a bit of peer review before it gets released onto the world.
Source at:
This is it programming a Uno:
Atmega chip programmer.
Written by Nick Gammon.
Entered programming mode OK.
Signature = 1E 95 0F
Processor = ATmega328P
Flash memory size = 32768
LFuse = FF
HFuse = DE
EFuse = FD
Lock byte = CF
Bootloader address = 0x7E00
Bootloader length = 512 bytes.
Type 'G' to program the chip with the bootloader ...
Erasing chip ...
Writing bootloader ...
Committing page starting at 0x7E00
Committing page starting at 0x7E80
Committing page starting at 0x7F00
Committing page starting at 0x7F80
Written.
Verifying ...
No errors found.
Writing fuses ...
LFuse = FF
HFuse = DE
EFuse = FD
Lock byte = CF
Done.
Type 'C' when ready go continue with another chip ...
Time taken: 1 second.
Inspired by your loader
Ah! Yes, that's the way to do it; there are a lot of assumptions and copying that went into optiLoader that have proven less than wonderful since it was first written.
It might need a bit of peer review before it gets released onto the world.
It looks nice. How come the signature table includes a bunch of devices that it doesn't actually know how to program?
Are you going to include the host-side program to produce C data structures from .hex files?
The signatures are there because I had them anyway for the "chip detector" sketch. May as well say it is chip X, but we can't put a bootloader on it, rather than "I don't know what this chip is".
Are you going to include the host-side program to produce C data structures from .hex files?
Yes, that's documented here:
It's a tiny bit fiddly, I did it with a Lua script running inside my MUD game client. You could make it stand-alone, but the client environment had a file picker, MD5 sum, bit manipulation, and other stuff like that which isn't core Lua. The page explains how to set it up, the stuff is all free, no problems with that.
Basically it reads the .hex file and stuffs the hex bytes into a memory image (to cater for the occasional gaps where there are FFs). Then it sumchecks the image. It also allows for the high-order address byte if you are over 65535.
Thank you,
Nick, i´m going to look in your examples an try to understand and cross them with Adaloader and a bit of optiloader 
Just to clarify, the size of the program is not a problem, because, the idea is to use a ATmega328P to read the .Hex file from the SDcard and write the Flash of a ATmega2560.