Hi I have a weird problem with my arduino Yun where I can not get my head around and I would like some input from the smart guys here, to find my problem. My problem is with a sketch for the arduino Yun (which is a leonardo). The sketch is work in progress and all parts have worked fine. But I seem to get problems at different locations, then they go away; the sketch works fine for a while and then a problem appears somewhere else. The problem I currently face is at startup time. It looks like the setup method is not called when the problem appears. I think so because the serial part (/dev/ttyACM0) is not visible on the linux side and I moved my LCD code to the beginning of the setup code and the LCD does not respond to resets of the leonardo.
I'll start the story at the virtual SerialBridgeCommunicator::setReceivedMessage SerialBridgeCommunicator is derived from SerialCommunicator and adds "load" and "save" functionality using the bridge to my SerialCommunicator class. To be able to do so I overload the virtual SerialCommunicator::setReceivedMessage but this stopped working. Using SerialCommunicator instead of SerialBridgeCommunicator works removing the overloaded setReceivedMessage and it works. Putting the overloaded setReceivedMessage back in and it failed. I worked around this by copying the code in SerialCommunicator that calls setReceivedMessage to SerialBridgeCommunicator. Because the code in SerialCommunicator that calls setReceivedMessage is now dead the optimizer removes is and the whole solution is smaller in size :D but less easy to maintain :~
Now setup is called but fails very early in the call Bridge.begin(); (this is my mini version of Bridge not the official bridge) So I add some Serial.print statements to Bridge.begin() to find where it fails. result setup is no longer called. I removed the Serial.print statements and the setup works again and Bridge.begin() does not return :roll_eyes: Just like the setReceivedMessage this code worked and I can repeat the problem and I have no clue why. looking at the compile output I see (when it is working)
Program: 30194 bytes (92.1% Full) (.text + .data + .bootloader) Data: 2037 bytes (79.6% Full) (.data + .bss + .noinit)
And when it is not working I get
Program: 30624 bytes (93.5% Full) (.text + .data + .bootloader) Data: 2037 bytes (79.6% Full) (.data + .bss + .noinit)
Before anyone screams the program is to big to fit. As this is the yun I can easily upload without bootloader. I have been running without bootloader on the yun for quite some time now. I thought maybe size is the reason. So I removed the print statements in Bridge.begin(); and added
Serial.println(F("Test 2222222222222222222222222222222222222222222222222222222222222")); Serial.println(F("Test 2222222222222222222222222222222222222222222222222222222222222")); Serial.println(F("Test 2222222222222222222222222222222222222222222222222222222222222")); Serial.println(F("Test 2222222222222222222222222222222222222222222222222222222222222")); Serial.println(F("Test 2222222222222222222222222222222222222222222222222222222222222")); Serial.println(F("Test 22222222222222222"));
To make the program the same size and indeed setup is not called.
As I use my eclipse plugin I made a sketch with the same size in the arduino IDE (I had to change boards.txt to tell I removed the bootloader) and the problem did not occur. In other words there is no general size problem.
Because the setup is not called I suspect the class constructors cause some memory overwrite. However I verified (my library classes) and I don't see anything that may look like "dangerous code". This is because in the constructor I copy data to a class variable which is used in the setup call I have in nearly all my classes. the copy is a pointer copy or a very basic data type. I also don't use dynamic memory allocation and I refuse to use String (that is part why I modded the bridge).
I use a lot of libraries but all are from good sources ( except mine that is XD ) Here is the list (the ones with a * have been written by me; part of them are available at github)
Any ideas on how I can nail the problem are welcomed. Best regards Jantje