Go Down

Topic: Arduino 0004 broke my sketch? (Read 6564 times) previous topic - next topic



I had a sketch perfectly working with 0003, but it doesn't work at all with 0004 (even after getting it to compile without errors by switching to the 0004 serial API as well as including <avr/eeprom.h> for accessing the eeprom).

What the sketch does is read in words from serial and "morse" them via a LED connected to pin 13. I experimented a bit with it in 0004, but there seem to be strange things going on internally, I just don't get it why it worked in 0003 but not in 0004?

Maybe someone of the more experienced forum members could have a look at it? Below are links to the version for 0003 that works perfectly and the port to 0004 that doesn't work at all.

Thanks in advance!



In Arduino 0004, your sketch is compiled as C++ instead of C, which changes a few things.  In particular, it's possible the eeprom functions don't work as expected.  There's a lot in your sketch, making it hard to debug.  Can you try to narrow it down to the smallest example that demonstrates the problem?  


hy gck

here perhaps your answer.
sorry it's in french section of the forum but code should be international ::)






well, the eeprom functions seem to work fine.

I'll try to narrow down the problem later today (need to go soon), but what confuses me is that even the Serial.print at the beginning of setup() doesn't send anything, just a few lines into the code. It seems as if everything is broken  :'(

Mellis: In my loop function, there are three parts of code (each executed when certain conditions are met): If you kill the input parser (first if-construct) and the morse-generator (last if-construct) by prefixing the if-conditions with "0 &&", I get at least the output from Serial.print in setup() (it also reads the words stored in my particular board fine from the eeprom), without killing these 2 parts, I get nothing at all... maybe that can help you nail the problem?

Even better, when I do not kill the last if-construct completely, but place a "return;" right after the line "previousMillis = millis();", I get only garbage output from serial rather than the start-up message...

I also tried compiling by hand with avr-g++, passing the -pedantic flag, but no useful warnings showed up...

My gut feeling is telling me that my problems are related to the new serial API somehow in conjunction with millis(), at least that's the picture I got so far from playing around, even though I can't nail it down... I'll try to do another simple sketch later to see if I can reproduce any problems combining millis() and serial...


ok, I tried narrowing down the problem, but it is apparently not possible: Apart from the stuff already said, putting in additional test Serial.print("") messages leads to totally unpredictable effects: some come not at all, some come garbled, etc...

Is there anything else we should know about the new Serial API, like a minimum time that has to pass between two consecutive strings written to serial?

I know my code is long and rather complex, but as far as I know (apart from some really arcane constructs), C++ should be compatible to C, so the problem can only be somehow connected to my usage of the Serial API and millis() (the only Arduino-specific stuff I use in my sketch, apart from lighting the LED, but that can't be the problem)... And it *did* work in 0003, compiled as C...

I'm somehow out of ideas of where I could start looking for a problem...


One thought is that the problem might somehow be related to the amount of RAM used by the sketch.  Adding constant strings will eat it up, and may lead to strange results.  What if you try removing/shortening your string constants?  It's also possible that the Serial functions are buggy, but that seems less likely.  Thanks for looking into this, and anything else you find out would help us fix the problem.


Ok, I played with it again. Removing all my string constants that get written to serial and shortening the two input arrays I use from 128 bytes to 16 bytes didn't fix my problems...

What I found out is the following, however: In my board, I already have a word stored in the EEPROM, so the sketch starts to morse immediately when you power up the board. Around line 278 (plus minus a few because of the debug messages I added here), I have the line

Code: [Select]

letterInd = (char*)morseCode[arr_ind];

morseCode is the array holding the character arrays that make up the letters in morse code (they are declared as "const" arrays in the beginning of my code). While arr_ind is computed correctly, all entries in morseCode seem to be NULL?

I verified that by placing

Code: [Select]

Serial.println(arr_ind, DEC);
Serial.println(((int)morseCode[arr_ind]), DEC);

directly after the above code line, the second statement always prints "0" while arr_ind is fine... As soon as letterInd is accessed later, the program most likely crashes or continues with garbage values read from address 0...

So it's maybe really RAM-related, but now that I removed all string constants and shortened my input arrays, can it really be that Arduino 0004 claims that much RAM more for itself than 0003 so that it breaks my sketch? Or is it somehow that my array declarations are valid C but not C++?


It's possible the array syntax works in C but not C++.  Since you don't use (or at least I didn't see them) the individual letter arrays, try declaring the array in a single statement, e.g.:

Code: [Select]

const char morseCode[26][5] = {
 {1, 3, 0}, {3, 1, 1, 1, 0},  // ...


I tried it, I even tried declaring morseCode as a one-dimensional array (using chunks of 5 bytes per letter and initializing letterInd with &morseCode[arr_ind*5] for each letter), but still no joy...

I also tried compiling a little test program using my original syntax with the g++ compiler on my laptop, apparently the syntax also works fine with C++ because the test program works on my notebook, but the sketch doesn't on Arduino...

Maybe it's really a RAM issue, but can it be that Arduino 0004 really uses so much RAM for itself that my array won't fit in anymore? I'm really a bit puzzled, using my original syntax, all values of morseCode are NULL, using the syntax you suggested (putting the sub-array directly into the huge one) leads to morseCode being an address, all of them pointing to NULL instead of the sub-array, declaring morseCode as one huge array leads to it being filled with NULL again...

The funny thing is, on Arduino 0003, I can waste even more RAM (for example, making my input buffers larger) and it still works flawlessly... Is there any way to check for RAM usage of my program (now that I don't allocate anything dynamically, there must be a way to find out at compile time?)


Again, I spent some more time with that sketch:

Apparently, if I comment out the whole "loop" function (i.e. make it an empty function) and print out the contents of my morseCode array at the end of setup(), it works fine, i.e. all the values are in memory. As soon as I uncomment my loop() function again, the values magically disappear, hence it may be a RAM issue...

I tried to find out how much RAM 0003 and 0004 keep free for our own usage, using this sketch

Code: [Select]

// for 0004 : works until NUM = 295
// for 0003 : works until NUM = 314
#define NUM  314

int blah[NUM];

void setup()
 int i;

 // Serial.begin(19200);
 for (i=0; i<NUM; i++)
   blah[i] = i;
 for (i=0; i<NUM; i++) {
   // Serial.print(blah[i], DEC);
   printString(" ");
   // Serial.print(" ");

void loop()

As one can see from the results at the top, the difference is not that dramatical...

Now that I reduced my input buffer length from 128 to 6, commented out all my print statements with string constants, where do I lose the RAM? I mean, the whole morseCode construct only uses (if one assumes 16bit pointers) 26*5 + 26*2 = 182 bytes, 12 bytes for the input buffers, but I should be having 295*2 = 590 bytes in total to use... any suggestions?


Ok, now I'm absolutely convinced it's a RAM issue. I need to comment out the whole loop function to ensure that my array is completely in memory...

So there has been a massive reduction in allowed code size or RAM usage from 0003 to 0004, any ideas why? Also, is there a way to modify the build flag Arduino IDE uses to compile the sketches? Maybe certain optimization flags can help?

Any sort of help would be highly appreciated, I originally intended to build some standalones that run code of about the complexity of my morse example, so I'm a bit desperate...


I'm confused: your original sketch (http://stud4.tuwien.ac.at/~e0125448/arduino/led_morse_code_0004.zip) works fine on my machine, with one small change: I commented out the "return" statement on line 261.  I see the initial start-up message, the LED flashes out morse code, and the eeprom write appears to work properly (I sent "david;" <enter> to the board, the LED blinked it out; I reset the board, it said it found the word "david" in eeprom and flashed it out repeatedly).  Do you get different results on your machine?  If so, what platform are you on?  


May 13, 2006, 05:09 pm Last Edit: May 13, 2006, 05:11 pm by gck Reason: 1
Oops, that "return" statement wasn't meant to be there, it was a leftover from me playing around with skipping parts of the code to nail the problem...

Anyways, from your description, it sounds as if the sketch works as intended on your machine!

I'm confused now also, the 0004 version (or the 0003 version compiled and uploaded with 0004 of the IDE) doesn't work on my machine, various problems and unexplainable bugs that seem to be RAM related, such as the morseCode array not being in memory (or the arrays its entries point to)... I assume all the various problems can be traced back to that array not being in memory properly.

I'm on a PPC Mac, it does neither work on my powerbook g4 nor a powermac g5. I'll try to test it on a windows machine as soon as possible to make sure my board is not at fault. If you have a mac, testing it might also be interesting...

Anyways, thanks for helping!


I'm also on a PPC Mac.  Can you try again with the 0004 sketch on your website, with the return statement commented out?  What behavior do you observe when you run the sketch?


May 14, 2006, 02:40 pm Last Edit: May 14, 2006, 03:58 pm by gck Reason: 1
I checked it again on the macs. On the board where I do already have a short word in the eeprom, when I upload the sketch, the led would blink exactly once, then the board goes into a loop of rebooting every few seconds (the led blinks the same way like when I press the reset button). No messages at all appear in the serial monitor.

On my other 2 boards (both have no word in the eeprom), the board goes into that reboot-loop as soon as I upload the sketch, so I don't think it's because of faulty boards, again, no serial messages...

I'll try to check it also from a Windows machine as soon as I get access to one.

If it helps, I'm running 10.4.6 and use the latest drivers from the FTDI website (2.2.0). Other (less complex) sketches work fine...

Go Up