Arduino 0004 broke my sketch?

Hi,

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!

http://stud4.tuwien.ac.at/~e0125448/arduino/led_morse_code_0003.zip
http://stud4.tuwien.ac.at/~e0125448/arduino/led_morse_code_0004.zip

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 ::slight_smile:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1146607557

regards

eric

hi,

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 :cry:

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

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

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

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

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

int blah[NUM];

void setup()
{
  int i;

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

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) 265 + 262 = 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;" 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?

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?

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

You may need to upgrade the bootloader on your boards. If you have access to an AVR-ISP or a parallel port programmer, you can use the Tools | Burn Bootloader menu item to do this. Otherwise, you'll need to change an option in your preferences file so that Arduino 0004 will correctly handle the older bootloader.

When you reset the board, does it blink three times or flicker briefly? If the former, you may have a older bootloader that takes up 2 Kb of the 8 Kb of program space (flash) on the ATmega8 instead of the 1 Kb used by the current bootloader. When uploading your sketch, Arduino 0004 checks if it's too big for the ATmega8, but it basis its calculation on a 1 Kb bootloader. If yours is bigger, only part of the sketch will be uploaded, but the software won't know, and your board will continually reset, pause, reset. You can tell the Arduino environment the amount of space available for sketches by editing the upload.maximum_size variable in your preferences file (see: Arduino - Home for instructions on finding the file). Change 7168 to 6144, and the environment should correctly warn you when your sketch is too big.

If you need the extra space and can't burn the smaller bootloader, you may need to continue using Arduino 0003. Reducing the size of the core libraries (so your sketches can be bigger) is one of the top priorities for Arduino 0005.

Hmm, okay, now this is really strange...

When I reset my board, the LED connected to pin 13 flickers (i.e. blinks really fast) for a short time, so I assume I already have the 1k bootloader.

Then again, when I brought the sketch below your limit of 6144 bytes by commenting out some stuff, it worked... so it may really be that.

Anyways, I'll try to get hold of an USB AVR-ISP to reprogram the bootloader, but because of the led flickering rather than blinking 3 times, is it also possible that there's some sort of bug that makes the IDE assume the bootloader is 2k large when it's really just 1k and stops uploading the sketch prematurely? If it helps, the serial number of the board I'm using (with the bootloader that came with it) is 1372 (a USB pre-built board).

Good to hear 0005 will give us even more space to play around with!!

You might have a 2 Kb version of the bootloader that flickers instead of blinks. The Arduino environment uses only the upload.maximum_size preference, so it wouldn't be getting confused by the bootloader. Burning the current bootloader (if you can get hold of an AVR-ISP) should fix the problem.

Ok, I'll try that, thank you so much for helping me with this issue!