I’ve got an application that runs fine under debug. For debug deploy I’m using the USB. I’m sending commands to the Mini via Com2(UEXT3/4). Everything works as planned in debug. I send a command and I get an ack back as expected. I’m also flashing the LED on each char.
I move to the final deploy of the release version. VS2010 says it deployed fine.
BUT after a reboot (and I disconnect the USB), the LED doesn’t flash, NOT like in debug mode. I’m powering it via an external 5 v source on the 5v-9vIn pin.
I tried originally to use Com1, but could never get it to work with the USB plugged in. Had to move to Com2.
Any Ideas?
BTW, I know I’m getting power because IF I turn off the led flashing routine and Leave it turned on, after the reboot it stays on.
First, don’t dredge up an ancient thread I like this new thread
Next suggestion. Do you have GNDs connected between the PC and Fez? If you don’t you can run into issues because nobody knows what GND reference to use so you may never triggger data reception - which matches your problem statement. Thats one thing you get by default with a USB debug session because of the cable.
It does sound like a ground issue… I tried connecting the ground on the UEXT directly to the com port connection. Didn’t work.
I left the USB connected after the deploy and after I shut down VS. Didn’t work. It’s acting like the deploy isn’t working. The 3.3vdc is from the onboard reg is fine.
My next test will be to determine if the Com2 is the issue. Maybe run a loop that flashes the led, just to see if the program is really running.
I’m also wondering IF my processor type has to be set? I know IF you don’t create a custom processor type of x86 on a x64 machine when you are compiling win code, the resultant code will end up being x64 and it won’t work. Seems like a stretch… Especially if everyone deploys just by choosing deploy.
The program is running. Led flashes just fine. I also wrote out to the com port on boot-up successfully. So that elimintes ground issues and the com port seems to be working outbound.
It seems as though the com port interrupt is not firing for some reason. Wierd problem.
Well that explains why com1 didn’t work.
I’m using a FTDI TTL-232R-3V3 to make the com2 connection. I wonder if the 5v version is required? This thing is putting out ttl at 3.3v not 5.0v
GNDs must be connected. Send might work and recieve may not, I don’t think you should use confirmation that one works to assume that the other should. So what you need is GND from any header (UEXT is fine) connected ot the GND at the PC end. Since you’re using a FTDI adapter, make sure that it’s GND is not isolated from the PC.
This is exactly the scenario I have had running on a Fez Panda and a CANxtra (yes, different but not much, really) when they output info to a connected PC, via a USB - TTL UART controller that uses the CP2102 chip. GNDs are all linked.
How about this scenario. Deploy your app to the Fez and make sure it all works. Then quit any debug connection in VS, unplug your Fez from your USB port, and then reconnect it. That way your app will reboot, and start up, but you won’t be actively debugging it, and you know you have GNDs shared. Does it work as you expect then?
I’ll set up a repro if I get a chance tonight to prove it - can’t use a Mini as that’s one of the few Fez I don’t have sitting around as I don’t own one
I insured all the grounds were in place. And tried step three, leaving the usb in place and rebooting the app. No dice. Same thing.
I even tried moving from com2 to com3. Made no difference. Works fine in debug, fails to ever see the data coming in in standalone mode.
I even moved the sender to a ground isolated (except the FTDI ground of course) laptop, a little netbook. Same result debug works fine and standalone doesn’t see the data at all.
I’m gonna try using a physical com port (9 pin) next. But I’m wondering IF debug mode doesn’t do something to the handshaking on a three wire TTL com to keep the port open all the time? Something other than just issuing the UART.Open() command.
In my code I set up a serial port eventhandler in the main module. Then I proceeded to infinitely sleep the main module. In debug mode this worked fine.
In standalone release, the event was never raised.
Resolution:
I noticed when scouring the help files and others attempts at UART communications that very fiew used serial port eventhandlers. Most used a read within a while loop. Now I know why!
SO…I replaced the event handler and sleep with an infinite while loop. Put readuart in the loop and victory!!. Works fine in release and debug.
I see this as a .net micro 4.1 bug. I’ve been reluctant to move to 4.2 until I got this project finished. I’m not a big fan of alpha or beta code. It’s usually buggy.
I wonder IF .net micro 4.2 will carry this bug forward? I guess it’s time to load it and try.
Guys, thanks again for your help. It really helped alot.
Brett, you were right-on about the grounds. Although not related to the UART, I did find a cold solder joint on my I2C mux that was acting flaky. Thanks again…
Mike, You definitely could be right… I’m no professional c# programmer.
Here’s my code. Did I do something wrong?
This worked:
public static void Main()
{
UART.Handshake = Handshake.None; // Turn off handshaking
UART.Open();
UART.Flush();
var SendSResp = Encoding.UTF8.GetBytes("System Startup: OK" + '\n' + '\r'); //Alert me of valid startup
UART.Write(SendSResp, 0, SendSResp.Length);
SendSResp = null;
while (true) //Wait for input
{
UARTRead();
}
}
This didn’t:
public static void Main()
{
UART.Handshake = Handshake.None; // Turn off handshaking
UART.DataReceived += new SerialDataReceivedEventHandler(UartDataReceived); // set up an event handler
UART.Open();
UART.Flush();
var SendSResp = Encoding.UTF8.GetBytes("System Startup: OK" + '\n' + '\r'); //Alert me of valid startup
UART.Write(SendSResp, 0, SendSResp.Length);
SendSResp = null;
Thread.Sleep(Timeout.Infinite); //Wait for input
}
I like this new thread