Go Down

Topic: How can an Arduino crash? (Read 1 time) previous topic - next topic

Nick Gammon

maybe there is a better way...

Almost certainly. I got confused looking at that, and I imagine you are too. How about first just reading the data into a buffer without trying to decode it? You are doing strcmp, but I don't see any attempt to put a null-terminator in the buffer, so the compares will fail straight away.

And just explain this bit please?

Code: [Select]

          int x = 0;
          unsigned long milliSMS = millis();
          while(x < 20 && millis() <= (milliSMS + 200)){
            sms_number[x] = 0;

You are trying to fill a variable called sms_number with zeroes, but you want to make sure that the code doesn't take more than 200 mS doing it? Why?


Jun 16, 2011, 11:13 pm Last Edit: Jun 16, 2011, 11:17 pm by GekoCH Reason: 1
Hmm but I do read first the data into a buffer until a new line "\r" does show up. This gets then parsed by the code.

There is a mistake with the  while(x < 20 && millis() <= (milliSMS + 200)) this routine is just to clear the buffer of
sms_number to store the new number. Actually I don't need this one because it gets overwritten by the new number...

by the way the parsing works I can decode those message with this code...


Jun 17, 2011, 01:59 am Last Edit: Jun 17, 2011, 02:03 am by FalconFour Reason: 1
Here's how you crash an Arduino.

Code: [Select]
char myBuffer[17] = "----------------";
char happyFace[] = ":-) ";
void loop() {
 static int bufPos; // static is only initialized once, so we don't clobber it every loop.
 strcpy(myBuffer+bufPos,happyFace); // copy the happyFace string (up to the terminating 0x00 at the end) into myBuffer, at offset bufPos
 lcd.clear(); // wipe the screen
 lcd.print(myBuffer); // print myBuffer - that is, display characters from myBuffer until a 0x00 is reached.
 bufPos += strlen(happyFace); // add the string length of happyFace (4 bytes here), excluding the 0x00, to the bufPos.
 delay(500); // wait half a second

Looks innocent, right? Uses a buffer to employ "appending" a string onto another string, through use of a buffer-counter (I guess I could use a *pointer, but my in-head compiler doesn't utilize that yet ;)). So every loop, you'll have another smiley on the screen. hehe, cute.

Except that... once you reach the end of the available space... the program compiled, right? It does just what it's told... it just keeps on truckin'. It's only 17 characters long, but bufPos is an int, so it's allowed to run off into oblivion, +22, +36, +59... and it'll still write it there. Oops. So if you happen to be writing to an out-of-range buffer pointer, you start clobbering over unpredictable memory areas, many of which are in use around it (holding counters, variables, etc). Happy face bunny starts going Godzilla on the memory map. Guess what? Program crashes... at first the program will behave erratically, storing bogus values in your log or jumping to random places in the code. Then, once it finally finds an infinite loop to cozily settle into (like a while() loop that never ends), it'll "crash".

That code is too confusing for me to look over right now, but I just wanted to point this buffer issue out, since I saw a lot of pointers, pointer-addition, pointer-assignment, etc., going on in there. Quite possible that your buffers are just getting scrambled up with out-of-range addresses...


Thx for the explenation. Thats why I use:

Code: [Select]

       if (counter == (BUFFSIZ-1)){
         counter = 0;

so if counter for the buffer is  equal to the BUFFSIZ, the counter value gets back to 0 and the buffer won't get over its edge. The Message in the buffer will be worthless but in general i do send just SMS with 10 characters to the Arduino so every other SMS it gets will be rejected....

But can someone tell me how to parse the Information from a GSM Module. Not every sentence will start with a $ sign like the GPS they are different. Sometimes they start with "+" or "/n" or even "*"....

Nick Gammon

How about first just reading the data into a buffer without trying to decode it?

I had the right idea back there, I think.

Build up the buffer first in a simple, clear, easy-to-understand function. Then analyze it. Your code is so confusing with flags, numbers, tests, etc. that I can't say whether or not it will work, or crash, or anything.

Don't try to do everything (build buffer, analyze, handle overflow etc.) in one long piece of confusing code. It might be OK from your point of view if it works, but you have said it doesn't.

Go Up