Hi,

The debugger uses arduino Serial.print statements by default. These are well tried and tested so I would appreciate a look at your project. This should show some confusion or something different that hasn't been explained properly, we will amend the wiki if required. 

Please zip and email your sketch along with any sub folder to info [at] visualmicro.com

Thanks

Hi,

While attempting to include the solution Presumably .atsln) I find my files all over the place, from me attempting to make backups.

I would like to start a new project and include my 12 .ino files. (Arduino called them tabs)

Whatever I've tried brings the files into the solution, but when compiling I have errors that "xxxx" was not declared in this scope.

Please point me to an article that will guide me.

Possibly this has some bearing on the original problem, although that compiled fine.

Thanks for your patience
Don

Tim,

Totally my fault I'd renamed the extra files starting with numbers.

I now have a new project and need to ponder on it before sending it to you.

I'll report back 

Thanks Don

Hi Don,

I have had a look at your sketch and I think this might be a problem in the code however there are some things to consider and look at.. 

1) Please run your arduino in a clean instance of Atmel without a project open. Open the serial monitor and you will see the unprocessed RAW serial messages that the debugger is sending. You will see your string being sent in breakpoint #1 (if my memory is correct). Please confirm that the string appears empty after some use and also when it does start to appear empty please confirm if you see any corrupted serial data or values immediately prior to that

2) Your writeLCD(int intLine, String strMsg) function expects a String to be passed to it. I see your call ends with a constant string but I have no idea if the string you are passing is terminated with a null (/0) or if the Arduino is loosing the null termination. Anyway I can only assume that this is the problem and can't think if much else that would cause a debug packet to be correct but a string expression value to be wrong.

			writeLCD(0, tempArray[0] + tempArray[1] + tempArray[2] + tempArray[3] + tempArray[4] + tempArray[5] + tempArray[6] + tempArray[7] + tempArray[8] + " H:M:S");
			writeLCD(1," Saved! - wait");
			lcd.noBlink();
			FSM = 0;									// returns keyboard to normal
			delay(2000);
 

3) Interested to know what happens if you move the breakpoint up a few lines so that it is away from the lcd.print function.

Summary

The reason for these assumptions is that Visual Micro debugger just uses Serial.print() which is a well tried and tested Arduino function.

I look forward to some test results.

Hi Don,

Sorry my request assumed that you have already uploaded your code with debugging. 

Thanks

Hi Don,

Breakpoint 1 is not even being sent or hit or we would have seen it in the output. Breakpoint 1 is in the writeLCD() function.

Breakpoint 2 is shown in your trace extract and will be empty because the breakpoint is in your clearLCD() function and you have set it not to show a value. I notice that breakpoint 2 is also in a function that expects the caller to have allocated a global temp variable but I am sure you have that catered for.

Breakpoint 3 is positioned so that it only fires if (keyPad == "down")

You can switch on "tools>options>compiler>show build folder" where you will see the .cpp file that is actually compiled. You will see in this file that a serial.print() sends any watched variables such as strMsg for breakpoint #1

As I have said it is a simple system, I haven't heard of the lcd functions causing a clash with serial so maybe you should use serial print(strMsg) and see what happens.

Because we are using standard Arduino functions it's more likely that something is overwriting some Arduino memory. maybe temp being used before it has been populated or maybe a null value in one of the dtostrf conversions. Obviously you have a big sketch with a lot going on so I can't really look at it in a reasonable time frame.

One question I have is what does the lcd do if it is passed an empty string. Does it leave the previous values on the screen.

Maybe try adding break points before the writeLCD is called allowing you to individually report what is in each tempArray[n]

writeLCD(1, tempArray[0] + tempArray[1] + tempArray[2] + tempArray[3] + tempArray[4] + tempArray[5] + tempArray[6] + char(223) + "C") 

One good test would be to remove the breakpoint in the write and replace with serial.println(strMsg)

if you persist with the debugger I suggest watching the youtube tutorial on the debugger page. It might show a few things about the trace window that will help you see what is or is not happening.

Good thanks for the update, I hope it was that. If your sketch allocated memory dynamically then the Arduino can run out of memory but it normally just crashes.

I noticed a lot of strings in your code, obviously when working with a big LCD project this can't always be helped but maybe switch some of the constants from string to numeric such as "down" but removing serial.print(" some text ") and replacing with breakpoints can make a big difference. 

Obviously this is chiken and egg because people have to first be confident with the debugger and saving breakpoints (which are stored in the solution .asln and not with the project .cppproj.

Best of luck

It might be that the extension isn't navigating the libraries correctly.

What is in intLine and what data type is it defined as?

Might be worth emailing the [sketchname].cpp from the build folder after debug upload. Then at least we can confirm what serial statements are being used by the debugger and which variables are being reported.

If you also have time to rezip your project and email it with a link to this post we can try to test it for you. If you have non-standard libs then please zip them or provide download links

Thanks