EMX is not starting with COM debug interface

Hi All,

Maybe it is something trivial, but still…
I have switched the debug interface of my EMX module to COM1 by setting LMODE high or unconnected (actually, tried both options, but with the same result).
COM1 pins are connected to USB UART TTL connector, external 3.3V power source is used to power the device.
Everything works fine while the USB connector is connected to PC (regardless if debugger is running or not). Once I disconnect it from PC or remove it, power off the device, then power it on again and let it boot, it does not start the .NET code at all.
When setting LMODE to low and using USB debug interface, the .NET code starts perfectly even if USB is disconnected.
I am using .NET Framework 4.1, GHI NETMF SDK 1.0.18. Firmware and TinyBooter are updated for this version (v.4.1.8.0 and 4.1.6.0 respectively).
Unfortunately, I have to use COM debug interface because I need the USB client functionality.

Had anyone ran into same issue?
Thanks in advance.

Do you mean that the you can not deploy or you got some application predeployed on EMX (Like a blinking LED code) and it does not run?
What baud rate did you use?

Exactly, the blinking led :slight_smile:
The code is being deployed fine, either by COM or USB.
The problem is that when COM debug interface is selected, this code is not executed if the COM interface is disconnected from the PC.
I haven’t noticed this problem for quite a long time while I was launching the app from VS. When it got to standalone operation, this issue came out.

Connect MFDeploy through COM reset the device and take a look at the boot up messages. Maybe the application is raising an exception.

When COM is connected to PC, everything works fine. After the reset I receive the normal debug message and the app is running as expected - showing the regular diagnostic message.

Looks like I’ve found the cause of the issue - when COM1 is unconnected, the fantom data interfers with the loader. The .NET program started to run standalone after I have pulled down the COM1 RX pin.
Thanks, Joe - describing the issue helped me to think differently about it and find a solution :slight_smile:

That’s possible.
Sending the character % through COM1 let the device enters the bootloader mode on start up.

This has been described as an issue on USBizi as well, but I’ve never experienced it. It seems like it’s just up to chance whether the COM1 pins float high or low.

I second that. I had a relay plugged into 14. When debugging through Visual Studio, I didn’t have any problems. However, I could never get my program to run standalone until I moved the relay.