Help in programming the Atmega1284 with maniacbug-mighty-1284p.

leo72:

retrolefty:
Yes, that is a problem, and it's very likely that the sketch is not being loaded correctly after a certain size is reached even though it's less then maximum flash memory size. There is no AVRDUDE error reported after the upload, but obviously the blink program is not running after the upload. It's believed to be a bug in the bootloaders for large (but still legally sized) sketches. For instance when using the Uno's bootloader one can load up a sketch right up to near the flash memory maximum size limit, but with a mega1280 I can't even get close to near max size. Coding Badly is of the opinion that is a bug in older bootloaders and their interaction with AVRDUDE on large code size uploads. So if the 1284P bootloader is just a recompilation based on one of the older mega bootloader programs it may have 'inherited' the same problem. This should be investigated further but I'm afraid I'm not knowledgeable enough in software/bootloaders to be a direct help other then testing.

I guess a first step is for someone to try a different method to developing large sketch sizes just to make sure it's not my sketch causing the problem symptom. Anyone up for the challenge?

Lefty

There's a problem related to a bug inside the GNU avr-gcc compiler. If I remember well, the compiler cannot create code that can directly access data in FLASH is it is stored over the 64 kB limit. Latest versions of avr-gcc aren't affected by this bug, the one that is included with the Ardino IDE is.
You can upgrade the Avr toolchain to fix it. I did it for my Linux box.

I guess that could be it, but I think I've read it speculated in the past that it is something to do with the AVRDUDE/bootloader protocol of stk500 or stk500v1 that is responsible for this behaviour.

Sheesh, you would think as long as the arduino mega1280/2560 boards have been available that the exact problem and or solution would have been well known and published by now? I sure it's not common to write sketches greater then 64KB but you think a few have had the need?

Lefty

Sheesh, you would think as long as the arduino mega1280/2560 boards have been available that the exact problem and or solution would have been well known and published by now? I sure it's not common to write sketches greater then 64KB but you think a few have had the need?

Sheesh, that makes 4 sheeshs now. I'm not too surprised that Arduinophiles in general aren't
writing too many programs over 64KB, but you'd think some might have. For my part, the
control s.w. for my robot tank exceeded 32KB code and 2KB RAM way last spring, so I've
wanted a larger space chip in a small size board [ala 1284 & UNO formfactor] to keep growing,
but even 64KB will be gone quickly. Hmmm.

It's also amazing the 1284 chips have been the object of 2000-3000 posts now on multiple
threads, and the limitations aren't flagged everywheres. Guess I'll have to learn how to
bypass the bootloader.

Is it possible to develop code using the Arduino IDE, with its libraries etc, and upload those
.hex files via a regular ICSP programmer, or will they not run without having the bootloader
to bootstrap off of?

Is it possible to develop code using the Arduino IDE, with its libraries etc, and upload those
.hex files via a regular ICSP programmer, or will they not run without having the bootloader
to bootstrap off of?

Sure, the current IDE supports in the files/menu option of upload sketch using programmer that will use your selected programmer (such as arduinoISP) to burn the sketch directly into flash without needing a bootloader, in fact if the chip had a bootloader installed prior to uploading using programmer, it will end up with no bootloader, just the sketch when completed.

HOWEVER the big question is will this change the large sketch not large enough problem? That depends on if the root cause is the bootloader/AVRDUDE or if the compiler version is the root cause. I'll see if I can play around and see if I get different results using upload using programmer on my mega1280 board.

Lefty

So I tried uploading large size mega1280 sketches without using the serial bootloader, but rather the upload using programmer option using another arduino running the arduinoISP sketch as the hardware programmer. The results were no change in symptom, I still could not load a mega1280 board to near it's maximum flash size limit.

So that would tend to appear to lend credence that it's a tool chain version cause (Although there may still be an issue with AVRDUDE and the protocol it uses with the arduinoISP programmer sketch I guess, we would need someone with a different hardware programmer, such as a AVRISP mkII to test out the problem), and explain the reason the problem has not be addressed even if known by the arduino developer's group. I have read them discussing about upgrading the AVR tool chain for quite a long time but there appears to be a lot of resistance as the upgrade carries the possibility of breaking a lot of older sketches and library code and unless there was clear benefits identified, some question upgrading the tool chain?

Oh well, it's not as if I thought I could fix the problem by myself, I just wanted to more clearly understand if there was a real problem or not ( it's real ), what it's root cause is (probably the tool chain? ), and what if any fix one might apply to the situations (I'm stuck). So I've kind of reached my limit of usefulness and will just stand back unless asked something about the issue.

Lefty

lefty, do you know if avrdude was built by Atmel as part of an official tool set, or something
jinned up by freaks? If by Atmel, one might think they would have proofed it on their larger chips,
and it would be 100%. Microchip's tools like MPLAB are continually updated to reflect their newer
chips.

There's a problem related to a bug inside the GNU avr-gcc compiler. If I remember well, the compiler cannot create code that can directly access data in FLASH is it is stored over the 64 kB limit. Latest versions of avr-gcc aren't affected by this bug, the one that is included with the Ardino IDE is.
You can upgrade the Avr toolchain to fix it. I did it for my Linux box.

leo, have you tried uploading files > 64KB to your boards, and had the programs run successfully?

AVRDUDE is it's own independent open source project with no 'official' relationship to Atmel or Arduino that I am aware of.

Lefty

retrolefty:
AVRDUDE is it's own independent open source project with no 'official' relationship to Atmel or Arduino that I am aware of.

AVR Downloader/UploaDEr - Summary [Savannah]

Lefty

I notice that the avrdude version installed with IDE v1.03 is dated 2 Sept 2011, so it's fairly recently
updated. Do you know any of those people who you could contact about the > 64KB issue?

OTOH, the avrdude version supplied with enhanced ERW IDE v.1.03 is dated 5 Nov 2012, and that
IDE still didn't upload working code, re post #75. It sounds like there may be 3 problems needing
fixing: IDE toolchain, avrdude, optiboot/others.

I don't believe the issue(s) have anything to do with AVRDUDE directly. It's what protocol type any specific bootloader code is using to work with AVRDUDE, which can handle several different protocols of which some have no problem writing to large flash memory sizes such as the SK500v2 protocol. That would effect the ability to load large sketches I believe. The other related issue but different is the ablitiy to properly create large sketches using the PROGMEM attribute, which seems to be a AVR gcc compiler bug/limitation.

I truly believe we have not uncovered any new problems, or problems that don't have a work around. For instance I'm sure someone can easily create super large sketches that don't rely on using the PROGMEM command. I also believe the a 'correct' bootloader for any specific chip type that uses the SK500v2 protocol with AVRDUDE would be able to load such large sketches. It's just identifying all the correct pieces and parts and implementing them correctly in the custom hardware folder. I suspect the current 1284p bootloader is correct and would test ok with a 'real' sketch of large proportions if they don't utilize PROGMEM to build that sketch.

At least that is my current take on what we are seeing.

Lefty

I started a new thread on this issue, see if we can get any enlightenment?

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

retrolefty:
Sheesh, you would think as long as the arduino mega1280/2560 boards have been available that the exact problem and or solution would have been well known and published by now? I sure it's not common to write sketches greater then 64KB but you think a few have had the need?

Lefty

Yes I Do say that the current Avr toolchain that is included in the Arduino IDE doesn't let the user write a sketch that isn't affected by that bug.
The bug only affects the access of data in the FLASH memory over the 64 kB limit, not the execution of code in that space.

The problem is inside the avr-gcc compiler.
The bug that cannot permit to access data from the Flash put over the 64 kB limit has been solved in avr-gcc 4.3.5 (or 4.4, I don't remember exactly) but the Arduino IDE comes with avr-gcc 4.3.2, and the bug is present.

EDIT: Moreover, the avr-gcc 4.3.2 has another limit: it cannot compile functioning sketches bigger than 128 kB (64 kBword).

EDIT2:
here is the a bug segnalation concerning the 64 kB limit with the data access. It's dated 9 oct 2012, so it's recent.
http://code.google.com/p/arduino/issues/detail?id=1067

Here is the guide to update the software using the latest toolchian from Atmel:
[LINUX]: http://www.leonardomiliani.com/2012/come-aggiornare-la-toolchain-avr-alla-versione-3-4-1-linux/?lang=en
[WIN]: http://www.open-electronics.org/arduino-full-memory-upgrade-to-the-last-atmel-toolchain-version/

leo, thanks for the information. I know nothing myself about using the raw AVR toolchain,
just the Arduino IDE stuff.

My results seem to agree with you, in that PROGMEM usage > 64KB is broken, however,
I did manage to build a large program and upload to the mega2560, with binary size of
212,525 bytes, and which seemed to work ok. See post #13.

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

In the end, after everything these mega1284 threads have been through, I'm still
not certain why many people are having the uploading problem. I haven't needed
the low-pass filter on RX0, and my tests earlier indicated I couldn't even reproduce
the upload problem by running the RX0 line directly through the crystal area, or
under and between the xtal pins. So ????
...........

However, I did discover a sensitivity that I forgot to mention earlier. On my mega1284
proto-test board, I am using a 6-pin header to connect the FTDI cable and FTDI Friend.
Otherwise, the RX0 pin was floating.

I found you "definitely" need to have a pullup on RX0, for when the FTDI interface is
not connected. This stands to reason, of course, as you will otherwise get noise
injected on that pin. However, unlike essentially every "other" pin on the chip, which
will be floating unless specifically terminated, noise coming in on RX0 will actually reset
the chip.

I did this test by touching each of the 1284 pins with my finger [my usual try to kill
the chip test]. Doing this had no effect for other pins, but touching the floating RX0
pin "always" reset the processor immediately. So, this is interesting....

I read here that a 1283P owner suggested that these RX0 pin problems could be related to the PicoPower version of the chip.
Do you have a "non-P" chip to try if it shows the same behaviour (I don't have it)?

oric_dan:
In the end, after everything these mega1284 threads have been through, I'm still
not certain why many people are having the uploading problem. I haven't needed
the low-pass filter on RX0, and my tests earlier indicated I couldn't even reproduce
the upload problem by running the RX0 line directly through the crystal area, or
under and between the xtal pins. So ????
...........

However, I did discover a sensitivity that I forgot to mention earlier. On my mega1284
proto-test board, I am using a 6-pin header to connect the FTDI cable and FTDI Friend.
Otherwise, the RX0 pin was floating.

I found you "definitely" need to have a pullup on RX0, for when the FTDI interface is
not connected. This stands to reason, of course, as you will otherwise get noise
injected on that pin. However, unlike essentially every "other" pin on the chip, which
will be floating unless specifically terminated, noise coming in on RX0 will actually reset
the chip.

I did this test by touching each of the 1284 pins with my finger [my usual try to kill
the chip test]. Doing this had no effect for other pins, but touching the floating RX0
pin "always" reset the processor immediately. So, this is interesting....

I believe this is the same failure mode/symptom that people having trouble uploading via RX0, noise being injected via RX0 corrupting internal data bus.

Lefty

leo72:
I read here that a 1283P owner suggested that these RX0 pin problems could be related to the PicoPower version of the chip.
Do you have a "non-P" chip to try if it shows the same behaviour (I don't have it)?

leo, so far I have been using only the 1284 "non-P" version, and have had no problems
with those. Today I ordered some of the 1284P chips, so will see how those work in a
couple of days.

oric_dan:

leo72:
I read here that a 1283P owner suggested that these RX0 pin problems could be related to the PicoPower version of the chip.
Do you have a "non-P" chip to try if it shows the same behaviour (I don't have it)?

leo, so far I have been using only the 1284 "non-P" version, and have had no problems
with those. Today I ordered some of the 1284P chips, so will see how those work in a
couple of days.

OK. I stay tuned :wink:

i can verify atmel is correct stating that uart0 is a customer layout problem. a client came to me with an m1284p board that failed to upload and we found adding a guard ring around the pin fixed it. there were several other avrs showing similar problems over the years, 90s1200 and 90s8515 being infamous examples. in every case proper layout fixed it.

John, do you have any idea if adding a guard ring around the next-door crystal cktry will
have a similar effect?

most of the dozen or so occurences ive seen were spurious interrupts and resets due to fast signals nearby and not so much crystal issues. in the case i just mentioned and most others autorouted fill pretty much served as guard ring for the clock pins. maybe thats why this did not seems to be the cause for us. i do know there were several choices for a fix that worked and narrowed it down to resistor (no cap) right on the rx pin or ground ring. chose the latter because partlist and schematic stayed the same and much easier to refit existing boards.

A dozen - that's pretty serious. Can you explain the bit about "fast signals nearby" a little more.
What exactly are you talking about here? I'm not even sure what fast signals on an Arduino even
means, as I/O is pretty slow in general. The crystal oscillator is by far the fastest. Thanks.