FWIW, I got the Visual Studio/Visual Micro code to run 1 time out of about 10 tries.  I would then stop the code and try to compile and upload again, without changing the code, and it would not work.

Some time ago I was experimenting with the plain ESP8266 module and Visual Studio / Visual Micro connected with the correct interface.  It would do the same thing, work, then not work.

The Arduino IDE works every time.  I think that Visual Micro "reaches out" and uses the installed Arduino IDE's code.  I am thus at a loss as to why Visual Studio / Visual Micro is so pernickety by comparison.

Tozapid,

I tried your suggestion, and it does work.  I got the same result by setting Visual Studio to compile "Release".

However, I want the debugger functionality.  Have you figured out how to get the debugger to work?  For some reason, mine will work one time in five to ten tries.

Tim@Visual Micro wrote on Nov 10^th, 2017 at 6:00am:

Tim,

Thanks for the feedback.

Not to be a pest, but have you any idea how long before this issue will be corrected in a new release of Visual Micro?

There will be an update over the next few days. I have removed a delay() command from the esp debug startup which might be the cause of the wifi connect issue.

I have also updated the visualmicro.com esp8266 page with my test example which works in both wifi and serial mode.

So it will be useful for you to use the same test thanks. 

I found it worked in both release and serial upload/debug mode. The code I use also waits for the IP address to be established and gives useful serial messages to see what is happening during boot.

what speed are you setting in serial.begin() ?

are you terminating your prints with println(ln) or \r\n?

Tim,

I have tried to find println(ln) and cannot.

Tim,

I know that.  In your note of yesterday at 9:31pm you asked if I was "terminating your prints with println(ln)".  I do not know, nor could I find a reference to, "println(ln)" function.  It looks to me like it is a typo, but I am not sure.

This morning (USA) I have tried various things with no luck.  I have added "\r\n" to print(), I have added println() after print() statements, etc..

Also, breakpoint messages are not coming through.  For example, I put a breakpoint message at the beginning of loop() to trigger when "millis() % 5000UL == 0" and display "loop() running", but the message never appears.

Even fixed breakpoints, i.e., stop at this line, do not work.

I have tried the code directly in the Arduino IDE standalone and the print functions do not print there either.  That is only a "Release" version, so to speak.

That one application using Visual Micro will Serial print, at least some of the time, and another will not is puzzling and appears to be beyond anything I can figure out.

It appears to me that something is interfering with the the Serial call or the Serial.print call.  That debug breakpoint messages do not get through may be related, but I do not know.  That is, something deep is going on.  The Blynk people, per a forum post, say that their code is just an adder, i.e., it does nothing to change the Arduino functions in question.

Have you ever used the debugger before?

Please give screen shot of full ide with status bar, trace and code when the break point is stopped in the loop.

Does click the "Continue execution" on the breakpoint properties and also adding a "message" to the breakpoint show correctly in the trace when the app is running?

Tim,

I sent the two screen shots in the last post.  I have also played with the application while following the Visual Micro instructions for debugging, just to be sure I was not missing something basic.  No change.

I said in the original post that I am using a "HiLetgo ESP8266 NodeMCU LUA CP2102 ESP-12E" board.  Since it is compiling and running properly, I am guessing that that is not the problem.  I just wanted to bring it up again to be sure.

Tim,

I have removed all the breakpoints from the code, just to eliminate any possible issue.  The compiler has been set to "Release".  Still, no output from the Serial print commands.

I know the loop() is running since the other part of the Blynk application is on an android tablet.  The display on the tablet changes as particular GPIO pins on the NodeMCU have their digital states changed.  That can only happen if the loop() is looping.

Current screenshot image is attached.

Sent, per your request.

Tim,

I do not understand what you are asking for.  What is autocode for an esp8266 HUZZA?

I need an authcode for the blynk service and the one in your code was rejected I will try your email over the next day or so thanks.

Does all the serial show in the arduino ide?

Tim,

Has your investigation uncovered anything?

I tried the Blynk example and it's working okay for me. It works both with and without debug enabled.

I was testing with a huzza that has less pins. I found the board would crash a lot if I attempted to set the pinMode for invalid pins. The board is obviously sensitive to using pinMode on pins that do not exist. It might be unrelated but I suggest that you do not use pinMode on pins you are not using. 

I was only testing so i hard coded leftDoorOpen = true and commented the pinModes.Otherwise test was same as your but without the your debug #define.

// Set GPIO pin modes
	//pinMode(Unused10, INPUT_PULLUP);
	//pinMode(Unused09, INPUT_PULLUP);

	//pinMode(Unused16, INPUT);
	//pinMode(leftDoorInput, INPUT_PULLUP);
	//pinMode(rightDoorInput, INPUT_PULLUP);
	//pinMode(Unused00, INPUT);
	//pinMode(Unused02, INPUT);
	//pinMode(backDoorInput, INPUT_PULLUP);
	//pinMode(Unused12, INPUT_PULLUP);
	//pinMode(Unused13, INPUT_PULLUP);
	//pinMode(Unused15, INPUT_PULLUP);
	//pinMode(Unused03, INPUT_PULLUP);
	//pinMode(Unused01, INPUT_PULLUP);