I ask because the bottom of the link says:
"RESOLVED: I modified the optimization from -O2 to -Os and NO ERRORS! and now the bootloader is working (led flashes correctly) :D"
you say nothing flashes...
also in your LAST posting with commandprompt, there is no such optimization switch...
I hate to say....mmh, are you shure about your ledwiring?
Have you checked/wired ResetPin?
In my opinion, it should work already if you patched files in 1284p Hardarefolder like for 644p.
After much frustration I have tracked all my issues down to a breadboard with many faulty junctions....
I did end up getting the bootloader to blink the LED again a bad junction. This is to say the least frustrating. I have not been able to upload code as I am having trouble finding good connections...
Ok here is were I am. I have it so that arduin 18 is able to burn the boot loader correctly, and the status LED does indeed blink while it is in the boot loader however the bootloader does not work. The code downloads and during the verification process all 0xFF is returned. with the modified adaboot loader that chrisS linked too.
Check clock Fuses / connection... I think Fuses maybe the Problem...
I know... blinking works...
I got much 0xFF's while testing with 644P.... and the answer where in my task that I used wrong Capacitors for Clock-Quarz. I used micoFrard not Pico... that happend by me.
Checkit... it may help you.
Try the latest AVRStudio for test to burn Bootloader... without IDE... still supports 1284p.
The thing is... Bootloader Position in Flash is in relation of Flashsize at all.
So the Bootloader has to be on a specific position in flash to get working.
This is a information got on the first posts i posted.
UPDATE 2:
I found that maybe the problem was "simply" the different LDSECTION value that I have to change for the 1284P.
So, as the datasheet say, for a boot size of 1024 words (2kbytes) the boot reset address is 0xFC00 then the LDSECTION will be LDSECTION = --section-start=.text=0x1F800 (0xFC00 x 2 = 0x1F800)
The value of 1F800 is even confirmed calculating it starting from the flash size (128k = 131072 bytes - 2048 bytes = 129024 bytes = 0x1F800)
Here the poster calculated 1F800.... for a 2048 Bytes Bootloader... i think with -Os parameter we should get 2048 Bytes....
If you don't have any positive results... maybe you think about UsbAspLoader... it's a Bootloader which emulates the Usbasp-Programmer for progranmming Mcu itself.... so you are able to boot, and use the ide to programm your sketches in Flashmemory like you want to.
Disadvantage, cause of use of Digitalpins instead of USART you arne't able to use virtualcomport-Communication....
For simple Programming purposes it should do the job.
UsbAspLoader ist a v-Usb Projekt (ArduinoCompatible) to get rid of FTDI (etc.) Chips... to include softwareusb directly inside of the mcu Bootloader....
Well I can program the chip just fine with the ICSP connection. Its just the bootloader thats giving me issues. If I could easily use the arduino environment with a programmer I would be happy. Still I would like to get the bootloader working, I have gotten no further...
ok, if you want to use the ide to programm... have a look at UsbAspLoader... again.... it is a bootloader which emulates a programmer to allow programming via IDE directly to the chip itself without external FTDI or something like this.
Have you made any further progress with this? I had been following the thread, but no sign of updates for a while - didn't look like you were too far away! Extra hardware serial ports would be really useful for me, without the unnecessary expense of a mega, and the 1284 would have more RAM than a sanguino.
Thanks!
I do plan on trying again but I haven't had time to mess with it as of late. Id probably be more apt to try if I had a sanguino board to use this on and not the flaky breadboard I have been using (keep getting loose connections ect its a very very cheap breadboard ).
I have a theory(well I know this is at least part of the problem) on why the modified adabootloader does not work. It stems from the fact that we are now dealing with a device thats entire flash space cannot be addressed by a 16bit value and additional modifications will be required to allow for the extended flash to be worked read/written too. I have attempted to make the changes by but do not know if my changes are successful as I have not had time to test them. Look at where the m1280 has special stuff done to its addressing vs the other devices which do not. This would in theory explain why I'm receiving back all 1s on read back as if the system is erasing the rest of the flash it would wrap around back and erase the program (I don't know if it does that or not but hey).
The Program counter on the AVR chips is a WORD counter, so a 16 pit program counter deals with 128K bytes (64K words)
THe standard STK500v1 bootloader works up to the 128K limit. It does NOT work for the full 2560 and it has comments in the code where the fix needs to happen.
I have successfully made the bootloader to work on the 2560 but you can only use 128K.
The standard mega bootloader should work with just fine. You might have to change some of the fuse bits if there any differences.
I was referring to the flash byte reads which the original patch fails to address (and incorrectly interpreted the writes would be bad as well). The modifications i was referring too were just changing the conditional compilation a bit to get the mega loader to compile for the 1284p.