Pages: 1 ... 4 5 [6] 7 8 ... 11   Go Down
Author Topic: Help in programming the Atmega1284 with maniacbug-mighty-1284p.  (Read 20821 times)
0 Members and 1 Guest are viewing this topic.
the land of sun+snow
Offline Offline
Faraday Member
**
Karma: 158
Posts: 2887
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Ok, I do have a mega2560 board [although only used a couple of times], and I tested
lefty's sketch. It works the same as on the 1284 chip. For arraysize = 4000, it uploads
and runs, but at arraysize = 7000, it uploads and verifies ok, but the sketch doesn't run.

And I am using Enhanced IDE ERW v.1.03 here, so the toolchain fix doesn't seem to have
gotten over into the latest version here either.

And yet another problem. With ERW 1.03, starting Serial Monitor does NOT send a reset
to the mega2560 board. I have to reset manually. Sheesh.

Ok, I went back to test Serial Monitor on both IDE 1.0 and 1.03, and they both send a
reset to the atmega2560 board when you open Serial Monitor. So, triple sheesh - it's
aways something around this place!
« Last Edit: January 19, 2013, 04:34:43 pm by oric_dan » Logged

Greenville, IL
Offline Offline
Edison Member
*
Karma: 15
Posts: 1328
Warning Novice on board! 0 to 1 chance of errors!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
starting Serial Monitor does NOT send a reset

 The ERW author felt is was best to remove the reset feature/problem. It depends how you look at it. If you read some of his posts in the last few pages of his thread, he explains how to modify the serial monitor behavior.
Logged


Left Coast, CA (USA)
Online Online
Brattain Member
*****
Karma: 361
Posts: 17262
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

the land of sun+snow
Offline Offline
Faraday Member
**
Karma: 158
Posts: 2887
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Logged

Left Coast, CA (USA)
Online Online
Brattain Member
*****
Karma: 361
Posts: 17262
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Left Coast, CA (USA)
Online Online
Brattain Member
*****
Karma: 361
Posts: 17262
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

the land of sun+snow
Offline Offline
Faraday Member
**
Karma: 158
Posts: 2887
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

Quote
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?
« Last Edit: January 20, 2013, 01:10:10 pm by oric_dan » Logged

Left Coast, CA (USA)
Online Online
Brattain Member
*****
Karma: 361
Posts: 17262
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

http://savannah.nongnu.org/projects/avrdude

Lefty
Logged

the land of sun+snow
Offline Offline
Faraday Member
**
Karma: 158
Posts: 2887
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

http://savannah.nongnu.org/projects/avrdude

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.
« Last Edit: January 20, 2013, 02:19:53 pm by oric_dan » Logged

Left Coast, CA (USA)
Online Online
Brattain Member
*****
Karma: 361
Posts: 17262
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

the land of sun+snow
Offline Offline
Faraday Member
**
Karma: 158
Posts: 2887
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Logged

Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 325
Posts: 22498
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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/
« Last Edit: January 21, 2013, 05:45:33 am by leo72 » Logged


the land of sun+snow
Offline Offline
Faraday Member
**
Karma: 158
Posts: 2887
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

the land of sun+snow
Offline Offline
Faraday Member
**
Karma: 158
Posts: 2887
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 325
Posts: 22498
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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)?
Logged


Pages: 1 ... 4 5 [6] 7 8 ... 11   Go Up
Jump to: