Can't load large libraries to Duemilanove w/ ATMEGA328

howdy,
i'm looking to get some opinions on how to proceed with this issue. i've been working with Arduino for a couple months now doing mostly simple audio projects and coding from a Gentoo Linux machine using Arduino-0022 with the appropriate board selected. i first had an issue using MIDI.h and the MIDI.read() function with a got around by working with Serial.read() instead and interpreting the data manually. now i have this issue loading this piece of code.

#include <SD.h>

void setup() { }
void loop() { }

this code compile a sketch that's a mere 5492 bytes but throws the bootloader into a continual reset mode causing the LED at pin 13 to blink every half second or so. i've adjusted run.options.memory.maximum=2048 as well as fiddled around with other values and still no go. i can compile and upload other sketches fine as long as the sketch size doesn't exceed 4k (or so it seems). i can load the sd_raw libraries fine leaving the sketch around 2k, so that leads me to believe that it's some sort of memory allocation issue within the bootloader itself. i was curious if anyone else had any ideas or similar experiences. it's like i have an atmega328 with atmega8 capability.

i guess i'll just start working on updating the bootloader, but any ideas as to why this would happen are greatly appreciated. thanks!

-abram

yeah. it seems related to the sketch size. anything over 4.5k seems to hang the bootloader. wild.

i was finally able to get around replacing the bootloader to optiboot using the FTDI bitbang method. i was able to upload a sketch after selecting uno as the board in the IDE, but same deal though minus the continual blinking of the LED which i assume is just a difference in optiboot vs. the older bootloader. i've ordered a new chip with optiboot loaded on it, but i don't like that as a solution. i'm down to either the hardware or the compiler (more seemingly the latter since i have no problems updating and uploading). i might actually wait for the new chip to arrive before diving into setting up the whole cross-dev system again. it took me a while to get it working in gentoo.

Assorted linux avr-gcc installs have "problems" of various sorts, but this is the first time I've heard of someone linking a problem to sketch size. Make sure you have a "good" version of avr-gcc installed (search for "gentoo" in the forums for more info.)

Your issues don't sound bootloader related; more likely your sketch is crashing somehow (and perhaps restarting the bootloader.) Can you post the complete sketch? Is the Arduino an Uno or one of the earlier boards?

indeed. it's a duemilanove board though the chip now has optiboot installed. but yeah, getting the environment setup on gentoo was rather tricky, so i'm being pushed that way more and more. having tried a completely different bootloader several times, that definitely can't be the issue.

the sketch that i posted was complete. simple including the SD.h library cause the sketch to crash. user deif posted a stripped down sd_raw library to the forum (Arduino Forum) which contains a commented sd_raw_get_info() function. with that function commented, the sketch uploads and runs and actually prints an error (since i have no pins connected to the board yet). if i uncomment the function, the size goes to 4.6+k and crashes. i get no errors and it uploads fine. i've recompiled avrdude, upgraded the IDE, and now i'm left with avr-gcc and the system setup. i figured the strangeness was worthy of a forum post. thanks for you input!

I've never used the SD card library, so this is a complete guess. I'm wondering whether it allocates a large amount of RAM when you make that sd_raw_get_info() call. The amount of RAM it allocates might depend on the capacity of the SD card you are reading. Which Atmega chip does your Duemilanove have? The older ones had the 168, which has 1K of RAM; newer ones use the 328 which has 2K.

a good guess at that. the SD library is quite a hog in terms of memory but, from what i understand, only occupies a little over 500 bytes which comes from the 512 byte buffer for addressing the FAT table in 512 byte blocks. mine is a 328 chip though. there was another thread where someone mentioned problems loading Serial.begin() and the SD library at the same time which turned out to be a limitation of the 168 chip. the 168 chip however is at least able (according to that thread) to handle the library by itself. my board can't even do that. :slight_smile:

i've come across some issues with Gentoo / Arch distributions have issues with certain functions (like millis() and delay()), so i've been scouring the sd_raw library for use of those to no avail. i suspect at the moment the culprit is the avr-gcc compile i did manually since crossdev's emerge of gcc doesn't compile avr-g++ which is needed by the IDE to compile the sketch. i recompiled binutils last night and it's still the same issue so i guess it's onto the gcc debacle.

btw gcc is version 4.3.3. updating to 4.3.4. i'll assume that 4.4.x and 4.5.x still have problems on the AVR platform.

and voila. compile with SD.h was successful after compiling binutils, gcc, and libc from scratch using Building and Installing the GNU Tool Chain as the model. i found it a lot easier than trying to cope with crossdev and the lack of attention placed on those repositories. i wound up using gcc version 4.3.6 instead and all is working.

thanks so much for the help!

I'm glad your perseverance paid off!

Hello Abram, I have the same problems like you with the SD card, but i can not understand your guide at all, please could you be more explicit about how did you fix it? for example which version of binutils and libc did you compile. Did you only install this three packages: binutils, gcc, and libc ¿Why i can't install thems directly fromn the gentoo portage or the overlay using USE="-openmp" crossdev -t avr -s4 --gcc 4.3.6-r1 --binutils 2.20.1-r1 --libc 1.8.0 --without-headers

Thanks in advance!