Hello VM Debugger Forum.

I need to run a debug version of my VM/Arduino code without being attached to Visual Studio.

For testing purposes, I have a program that monitors the serial port and responds appropriately to the requests made by the VM/Arduino code. It communicates via the D0/D1 serial connection.

I am seeing "VMDPV_1|1_VMDPV" messages that, when connected to VM, appear once and everything afterward works fine.

When not connected to Visual Studio (via USB port) I see streaming "VMDPV_1|1_VMDPV" messages.

My understanding is that these are related to how the VM environment enables debugging.

So, two questions:

Is there anyway to disable these messages in a debug build?

Is there a response I can send from the monitor program that will trick the Arduino/VM code into thinking it is connected to VM?

Thanks for your suggestions,
Tom

Hi,

If you make a release build the messages will go.

The debug can't currently be disabled without making a release build however it's on the cards because the newest ESp8266 UDP debug works that way so will shortly become an option for all boards

I don't understand what you are expecting the result of the next question to be


Quote:

Is there a response I can send from the monitor program that will trick the Arduino/VM code into thinking it is connected to VM?

You also have the softwareSerial debug option is you need to keep the serial port free

Hi Tim,

Thanks for the info. I wanted to avoid doing a release build for early development soak testing, but it may be inevitable. I'll look into the softwareSerial debug option.

With regard to the second question, I was guessing that the debug environment saw the "VMDPV_1|1_VMDPV" message and sent an acknowledgment of some sort that prevented the streaming of these messages (like an ack to say, 'Yep, the debugger is ready.'). My hope was to simulate that response in order to stop the streaming messages.

--- Tom

Hi,

The arduino doesn't rely on any messages from the pc to determine what it sends to the pc or when it hits a break/pause (as opposed to trace). The pc only sends a message of control when you click continue/F5 or change the value of a variable in the watch window.

Hopefully the next release of visual micro makes it quicker to switch builds between release and debug avoiding the full compile you see at the moment.

I will also add a switch to the todo list that allows the debug to be skipped entirely.

Finally I am still not entirely clear about this statement.


Quote:

The "VMDPV_1|1_VMDPV" message and sent an acknowledgment of some sort that prevented the streaming of these messages

VMDPV is sent once at startup of the arduino and receives no response. After that you only see messages if a break/trace point has been added to the code or reports such as digital pins and analog pins have been enabled. These streamed items have a different signature to VMDPV, either VMDPE or VMDPR

If vMicro>General>Tutorial Mode is enabled a streaming example break point is automatically added to the code prior to compile if no other breakpoints exist. Maybe it is the tutorial breakpoint that makes you think something always has to stream? Hopefully if you hover over the break point and you see a tool tip that explains what it is?

Hi Tim,

OK, so my guess about what was going on with the VMDPV messages was incorrect. No worries, it was just a guess.

I checked the various settings you mentioned (tutorial mode, breakpoints, trace points), none of these are set.

I am running a debug build on the Arduino. The Arduino is not connected to the PC via the USB. However, it is connected by a three-wire serial connection (DO/D1/GND) to a USB-to-serial cable where the responder program listens for and replies to commands. It is on this port that I see the streaming VMDPV messages ("????VMDPV_1|1_VMDPV"). Note: Power is supplied externally via the DC jack.

I only mention this because you stated that the VMPDV message is sent once. In the above configuration, it is sent repeatedly.

Thanks again,
Tom

Thanks for explaining.

If VMDPV is sent repeatedly it means the arduino is crashing and constantly restarting. VMDPV is sent from the setup() method so can only be called once per power up.

Have you used the debugger with your board and core yet?

I have used the debugger, but not recently.

What I am seeing is that if the device powered by the USB (even without Visual Studio/Visual Micro running), there is a single VMDPV_1|1_VMDPV sequence which the responder program ignores and from there things function as expected.

If I unplug the USB and power the Arduino via the DC jack, I see the streaming VMDPV_1|1_VMDPV messages.

Sounds like the DC jack has a very low power rating. Usb gives up to 0.5 amp so check the rating of the DC, maybe it's only 150 or something low. What else is the board powering?

Hi Tim,

The board is also powering a single SPI NV-memory chip and a pressure sensor.

The power supply is 9V/1.7A, so it is probably OK. I have been using this power supply for the entire project (about a year) and, in the past, I did not see this problem.

I am going to try rolling back to the LKG version of the Arduino software and see if the problem repros there.

Note: I thought I was on the latest version of VM (1612.12, installed on 12/16), but the version shown in VS (Tools/Options/Visual Micro/Version) is 1.1611.21.12072.

--- Tom

You have the correct app version which is displayed in tools>extensions and updates.

What is the board?

Board is an Arduino Uno.

BTW, I tried the LKG test and saw the same issue.

Thanks. It doesn't make sense, must be some code that checks for something that doesn't exist which then crashes the cpu. However that's difficult to do with an Uno which would normally only reboot through lack of power.

I figured out what was going on.

It turns out that I had a bad ground on the serial port connection. Once that was corrected, the problem went away.

A bit of a happy/sad moment.

Thanks for your help.

Great thanks for the update