Re the following thread, several of us been trying to get sketches with upload files > 64KB torun on atmega1284 chips using maniacbug's optiboot, but with problems.

http://arduino.cc/forum/index.php/topic,139671.0.html

The files will upload and verify ok, but not run correctly. This was also found to be the case for atmega2560 boards. So, we're wondering where the problem is - IDE toolchain, compiler, avrdude, optiboot?

There may also be some problem with how our sketches are formulated - ie, in using large PROGMEM arrays, cf reply #57,

http://arduino.cc/forum/index.php/topic,139671.45.html

So the "specific" question here is ... is it known if optiboot itself will correctly handle sketch files > 64KB? Have people actually gotten these to load and run successfully?

I am not the author of Optiboot Optiloader, so I can't say for sure. However I did a rewrite to specifically handle the processors with more memory (such as the Mega) and this sketch works:

http://www.gammon.com.au/forum/?id=11635

Clarification: Are you asking about Optiboot or Optiloader?

Optiboot

The issue is testing loading of very large test sketches into boards such as the 1284P boards of different flavors and into arduino mega1280/2560 boards which don't have a modern opitboot bootloaders. It would be great if your 'Atmega chip programmer' sketch had more bootloader options for the mega1280/2560 boards. Also creating large sketches has been an issue as apparently using PROGMEM has a avr-gcc bug that won't allow it to correctly create large arrays in flash memory, even though they compile without error.

Actually, as I dig deep into the dark recesses of my memory (a scary place) I do seem to recall that this was an issue with Optiboot and westfw and I had some communication about it, and it was fixed. I'll review my email, but I suggest you (1) make sure you have the latest optibiit and (2) review its source for comments about this issue. I'll do the same.

The issue is testing loading of very large test sketches into boards such as the 1284P boards of different flavors and into arduino mega1280/2560 boards which don't have a modern opitboot bootloaders.

Lefty, what does that mean, "modern optiboot bootloaders" ?

My app (sketch) is much bigger than half the flash space in a 1284P and uses PROGMEM quite a bit. Optiboot loads and runs it perfectly.

The existing mega2560 as well as the older mega1280 boards use a older bootloader the has known problems, no proper WDT support, !!! monitor triggering problem, and we are not sure they can handle uploading past a certain size >64KB. Optiboot fixes a few (all?) of those issues, or at least we are trying to test and validate that. As far as the PROGMEM problem, it's not using it that is a problem, but rather if used to create arrays past a certain size that is the apparent problem.

Actually, as I dig deep into the dark recesses of my memory (a scary place) I do seem to recall that this was an issue with Optiboot and westfw and I had some communication about it, and it was fixed. I'll review my email, but I suggest you (1) make sure you have the latest optibiit and (2) review its source for comments about this issue. I'll do the same.

Well locating a optiboot bootloader for my mega1280 board has been a problem for me. And I'm not sure that the arduinoISP programmer uses the proper AVRDUDE protocol (SK500v1 Vs SK500v2 ?) to load bootloaders into the high memory addresses that the mega1280/2560 boards use and I have access to no other hardware programmer other then my USBtiny that is known not to work with mega1280/2560 boards.

I think all the basic problems are known and have solutions or workarounds, I'm just not able to assemble every thing together to really make valid tests.

Any one have a link(s) to very large size arduino sketches ( say 100KB and 200KB that don't rely on using PROGMEM to attain their large size?

OK, well we have two issues here. First is getting the bootloader onto the chip, which can be a problem with some programmers with > 64K words of program memory.

The second is, to have a bootloader that itself can handle the extra memory itself (effectively the same problem, moved to the bootloader).

I have seen so many incarnations of bootloaders, I am unsure which one work absolutely correctly. I believe the one which my bootloader-installer installs works correctly, but haven't tried a very large sketch (with that bootloader). I have tested the WDT issue though.

Please post technical questions on the forum, not by personal message. Thanks!

OK, well we have two issues here. First is getting the bootloader onto the chip, which can be a problem with some programmers with > 64K words of program memory.

The second is, to have a bootloader that itself can handle the extra memory itself (effectively the same problem, moved to the bootloader).

I have seen so many incarnations of bootloaders, I am unsure which one work absolutely correctly. I believe the one which my bootloader-installer installs works correctly, but haven't tried a very large sketch (with that bootloader). I have tested the WDT issue though.

After much searching yesterday and today I finally located a optiboot hex file compiled for a mega1280 board in someone's site. I just was able to burn it into two different mega1280 boards I have using arduinoISP sketch from IDE 1.0.3 as the programmer type and they both took the new optibootloader without error. I tested both with a WDT testing sketch that would 'brick' a mega board with it's original bootloader, but now function correctly, so yea.

So the present arduinoISP programmer sketch has no issues burning bootloaders into large memory AVR chips.

So if anyone else is having trouble finding a optiboot for a mega1280 chip I will post it here:

And finally a WDT testing sketch that someone on this forum wrote that works fine on a Uno type board but WILL BRICK any arduino mega1280/2560 board that hasn't been upgraded with the opitboot bootloader, so only run it if you know what your are doing and have the means to reburn the bootloader to recover.

// Test sketch to see if WDT interrupts are handled properly by the bootloader

/* Warning Warning Warning this is a semi-destructive test in that if your bootloader does not reset WDT interrupts upon starting it will be forced into a tight loop of bootloader starts/WDT resets chip/bootloader starts again/lather rinse repeat. One can only recover to normal operation by reburning the bootloader with a ICSP programmer. If this sketch runs properly on a chip with a WDT aware bootloader, you will see continous serial output on the serial monitor.

For my part, related to the first post, I've tried a Mega2560 R3 board that I bought just a couple of months ago, and for the 1284, I think we've all been using maniacbug's latest version of optiboot, from here,

It should be easy enough to check the bootloader functionality; just upload via the bootloader, and then run verify with an ISP programmer.

I was looking at memory regions a little while ago, thinking that I didn't understand how the compiled code was supposed to work if the amount of data in pgmspace got large. Perhaps it just... doesn't.My understanding is that long jumps are supposed to work via "trampolines." A trampoline is essentially a jump table to the >64k target in the first 64k of memory, letting most things work with the 16bit pointers that the compiler likes to use. But if you have lots of pgmspace DATA, that's also located in the first 64k of memory (so that the pgm_read_byte() code can work, and I think it pushes out the jump table.

So sketches that have more than 64k of CODE might work a lot better than sketches with lots of data...

It should be easy enough to check the bootloader functionality; just upload via the bootloader, and then run verify with an ISP programmer.

I was looking at memory regions a little while ago, thinking that I didn't understand how the compiled code was supposed to work if the amount of data in pgmspace got large. Perhaps it just... doesn't.My understanding is that long jumps are supposed to work via "trampolines." A trampoline is essentially a jump table to the >64k target in the first 64k of memory, letting most things work with the 16bit pointers that the compiler likes to use. But if you have lots of pgmspace DATA, that's also located in the first 64k of memory (so that the pgm_read_byte() code can work, and I think it pushes out the jump table.

So sketches that have more than 64k of CODE might work a lot better than sketches with lots of data...

I think that is correct thinking. Now just to find some jumbo sketches the use code the nearly fills 128KB and 256KB chips.

Ok, I have a bit of information. I created large sketches by simply cloning a couple of digitalWrite() statements a gazillion times. I also cut back on the size of the PROGMEM arrays to a total of 16 KBytes. Then uploaded to both 1284 and 2560 boards. In bothcases, the sketches appear to work correctly afterwards, as evidenced by Led13 blinking properly as directed by the code.

The mega1284 binary sketch size was 84,276 bytes, and I added more code, so themega2560 binary sketch size was 212,524 bytes.

So it looks like IDE v.103, plus optiboot for both 1284 [maniacbug] and Mega2560 R3 chips, can handle sketches > 64 KB alright. Apparently, what they didn't like before were the PROGMEM arrays being too big.