Strange fault. LCD corrupts and arduino crashes

Projects General Guidance
1

I have built a project using my own PCB and it works fine. I included a programmer socket compatible with an FTDI lead and this has worked all the way through the build with modifications and updates.

All of a sudden after another update the device crashed with a corrupted LCD screen. I thought this was a loose connection and so took everything apart but it wasn't.

I picked up another build of the same device and then ran the same update.... This caused the same problem.

I have a programming switch using #ifdef and so turned off all the serial communications I was using as a debug and the device worked again perfectly......

I updated it again with the debug info and again the same apparently random LCD issues and crash so again I updated with the debug info off and again it worked......

The program is about 11K without debug info and about 15-16K with it.

It seems to be the program length that is causing an issue but the 328p that I am using should be 32K max shouldn't it!

Any ideas anyone?

2

You may be running out of RAM, overwriting variables, etc. Usually gets reported here when large arrays are used.
There are some memory utilization things you can use to see how much is being used.

3

If your debug code is using the String class, try rewriting the code without using it. The String class uses a lot of memory and allocates it dynamically, making the RAM usage vary as the program runs, and hard to predict. My personal view is that String and other classes that allocate dynamic memory (other than only at initialization time) have no place in an embedded system with limited RAM.

4

CrossRoads:
You may be running out of RAM, overwriting variables, etc. Usually gets reported here when large arrays are used.
There are some memory utilization things you can use to see how much is being used.

Thanks, I felt that it was likely to be something like that. There is not much in the way of variables, certainly not even 1K's worth I would guess.

There are 5 arrays with 16 entries each, 3 are unsigned int and 2 are "char* NAME[]" with entries that are 8 characters long each.

There are several long ints, ints and boolean variables and a few local variables but thats it.

The sketch includes: WProgram.h, Button.h, TicksPerSecond.h, RotaryEncoderAcelleration.h, EEPROM.h & LiquidCrystal.h

The actual program is not that long or complicated.

IMPORTANT NEW INFO.....

I originally built the device as a shield which attached to a genuine Arduino 328p reference board.

Next I took the standard setup as per the bread board like here : http://www.arduino.cc/en/Main/Standalone and added my shield making it all on one PCB.

It worked faultlessly until this happened !

If I upload the same sketch to an arduino reference 328p board with my original shield attached (so it should be effectively the same thing) then it works exactly the same BUT it continues to work even with the debug stuff.

The debug stuff is just basically lots of stuff like this:

#ifdef DEBUG_INT
Serial.println(""); Serial.println("-------------- Entering the inner loop --------------"); Serial.println("");
Serial.print("Number if times left = "); Serial.println(count);
#endif

So I can watch what is happening using the computer.

5

Given that extra info, it sounds like a hardware problem. I would check you have adequate decoupling first. Do you have a 5v regulator in your design, and if not, where are you getting the +5v supply from?

Also I recommend using a magnifying glass to check for short circuits between adjacent pins or traces, especially if your pcb doesn't have solder resist. My first atmega328 stripboard design had a couple of these.

6

dc42:
Given that extra info, it sounds like a hardware problem. I would check you have adequate decoupling first. Do you have a 5v regulator in your design, and if not, where are you getting the +5v supply from?

Also I recommend using a magnifying glass to check for short circuits between adjacent pins or traces, especially if your pcb doesn't have solder resist. My first atmega328 stripboard design had a couple of these.

Yes, using a 7805 regulator from a 9v battery. When the FTDI lead is plugged in the board gets it's power from the USB port via the lead. I have built several generations of the main board updating each one to the latest spec then changing the design in eagle and crating a new board. With that in mind I have four electrically identical boards. This same fault happens on both of the boards I tried.

Power supply shouldn't be an issue as it does it from the FTDI lead but basically I have a couple of 10uF caps either side of the reg.

What decoupling on the 328p is the accepted ideal?

7

cowasaki:
What decoupling on the 328p is the accepted ideal?

An electrolytic of 10uF or more (which you already have at the voltage regulator), plus a 100nF ceramic as close to the atmega chip as possible.

8

I have a couple of 10uF caps either side of the reg.

What about the recommended capacitors?

plus a 100nF ceramic as close to the atmega chip as possible.

You need more than one of these since there is more than one power pin.

Don

9

Maybe you can share with us your pcb design or program. I saw no details of either and am a bit surprised you are still getting plenty responses.

I have a theory but I rather see what you have. I have seen similar things.

10

Yeah, w/o more info, this like throwing darts in the dark.

11

I only have a 100nF cap on one side of the 328p so will add one to the other side and see if that fixes the problem.

Thanks for everyones help, if that doesn't sort it I will get back with more details.

12

There is not much in the way of variables, .

The debug stuff is just basically lots of stuff like this:

#ifdef DEBUG_INT
Serial.println(""); Serial.println("-------------- Entering the inner loop --------------"); Serial.println("");

To me, those two statements are at odds with each other.

("-------------- Entering the inner loop --------------");

is a crazy amount of RAM to waste on such low information content.

13

AWOL:

There is not much in the way of variables, .

The debug stuff is just basically lots of stuff like this:

#ifdef DEBUG_INT
Serial.println(""); Serial.println("-------------- Entering the inner loop --------------"); Serial.println("");

To me, those two statements are at odds with each other.

("-------------- Entering the inner loop --------------");

is a crazy amount of RAM to waste on such low information content.

The statements are enclosed in IFDEF statements so it really isn't a waste of RAM when the debugging is switched off :slight_smile: Since this happened I have split the IFDEF constant up and each function has it's own constant so I can turn on debugging during small parts of the program only. With debugging on all the relevant variables and EEPROM locations are listed as are the results of all decision making sections of code. If I was getting up to 29-30K and having this problem I would seriously reduce the amount of space used by the lines but it is happening at 10-15K hence the issue.

It works with the reference board and the only difference is the lack of a 100nF cap on one side of the 328p. I will add this as it does seem likely that this is the problem.

All the other variable information is stored in EEPROM and read directly from and written directly too the chip so that it is not lost when power is removed.

14

Well definitely a big thanks, just attached to my PC in the workshop to add the extra 100nF cap and realised that I had actually missed BOTH of the 100nF caps !!!! The 100nF cap on the board is on the RTS line between the FTDI lead and the 328p. It only took me a few seconds to move a couple of components and add the 2 caps. I will have to retro fit them to the existing boards but that shouldn't be an issue.

Once again help much appreciated. I will post back as soon as I am able to retro fit them. I'm off to work shortly and working all weekend so might even be Monday!

15

Hmmmm

Well I decided to quickly sort it and rushed down to the workshop. I've attached the two 100nF caps between GND and VCC on each side of the 328p.

No change.

It all works fully until I go over 15K.

I have the debugging split into 4 sections and any 3 of the 4 work without fault BUT all four cause the device to crash. It looks like a hardware fault as ANY of the 3 out of 4 sections work and the device crashed before it even reaches these sections.

Will try uploading another sketch of 18K to see what happens. I haven't got long so I'll have to be quick.

16

It sounds to me that you are running out of RAM. Try shortening the strings, e.g. instead of "-------------- Entering the inner loop --------------" use "-- Enter inner loop --" or even "EIL". There is a way to reduce the RAM usage of strings using the PROGMEM directive (see the Reference), but then it is more complicated to access them.

It's a shame that the Arduino IDE only tells you the sketch size (which I presume is the program memory size) and not the amount of RAM taken by static data. Does anyone know if the IDE can be configured to get gcc to generate a map file, and whether gcc gets run with string pooling enabled?

[EDIT: I just found instructions on how to recompile the IDE to generate map files at Arduino IDE Warnings And Map Files - Wiki]

17

Well just uploaded a VERY early version of the software but stuffed it full of another 15Ks worth of serial.println commands making it over 20K and it works...

So it looks like a software issue BUT the software works on the reference board.

Will have to carry on looking later.

Whilst I have your attention is there a shorter version of:

Serial.println(""); Serial.println("- OUT inner loop -"); Serial.println("");

in PASCAL I could do something like PrintLn(CHR(13)+"- OUT inner loop -"+CHR(13));

18

cowasaki:
Whilst I have your attention is there a shorter version of:

Serial.println(""); Serial.println("- OUT inner loop -"); Serial.println("");

in PASCAL I could do something like PrintLn(CHR(13)+"- OUT inner loop -"+CHR(13));

Try Serial.println("\n- OUT inner loop -\n").

I still think you are running out of RAM. When you added 15K of print statements, did you use different strings, or the same strings repeated many times?

19

I have just reduced the size of the text strings by 600 bytes and hey presto it all works perfectly, then logged back in and read dc42's post (great minds etc)!!

Luckily the program is virtually finished so should be ok other wise I would have to start stuffing things into the variable space in the EEPROM etc.

20

dc42:

cowasaki:
Whilst I have your attention is there a shorter version of:

Serial.println(""); Serial.println("- OUT inner loop -"); Serial.println("");

in PASCAL I could do something like PrintLn(CHR(13)+"- OUT inner loop -"+CHR(13));

Try Serial.println("\n- OUT inner loop -\n").

I still think you are running out of RAM. When you added 15K of print statements, did you use different strings, or the same strings repeated many times?

Thanks dc42, I keep replying as you do :slight_smile:

I will try the above. I've come from PASCAL (delphi) and assembly etc so I'm missing things like that :slight_smile: