Serial bluetooth device only works when debugging

Hi, 1st post by me :-) I have a Netduino and have added a 16x2 lcd display (par 4bit mode) and a Parani Bluetooth adapter (serial). When booting I send ATZ to the parani, and get OK back. But this only works when running from within VS2010 Express. If I just plug the netduino to the computer the display work, but not the bluetooth adapter. The display always work. But the BT-adapter only works when running with F5. Example: Attach netduino to pc: No response Run (F5): OK Run again (F5): OK Reset with reset-pin on netduino: No response No error on opening the serial port, no error on send, but I appear not to get any response from the device. Does anyone have any idea on what's going on? Currently it's too much code to post.

Hi Mats, Could you post a Fritzing diagram of your setup (or outline what is connected where in some way)? Also, just to double-check: have you tried sending line-by-line diagnostics data to the PC (using Debug.Print and watching the stream using MFDeploy + F5)? Also, have you double-checked that your Bluetooth device is still powered? Chris

Hi Mats,

Could you post a Fritzing diagram of your setup (or outline what is connected where in some way)?

Also, just to double-check: have you tried sending line-by-line diagnostics data to the PC (using Debug.Print and watching the stream using MFDeploy + F5)? Also, have you double-checked that your Bluetooth device is still powered?

Chris

Hi Chris,

Thanks for your answer, forgot about MFDeploy, thank you for that info.

If I have understood correctly, then: F5 in VS deploys code and "reboots" netduino, the same way shorting reset pin with gnd "reboots"?

I think there is a bug in SerialConnection.DataRecieved.

Here is my test-code:

class TestDebug
    {

        private SerialPort _serial;
        private OutputPort _led;

        public void Open()
        {
            try
            {
                _led = new OutputPort(Pins.ONBOARD_LED, false);
                _serial = new SerialPort(SerialPorts.COM2, 9600, Parity.None, 8, StopBits.One);
                _serial.ErrorReceived += delegate { Debug.Print("ErrorRecieved Raised"); };
                _serial.DataReceived += new SerialDataReceivedEventHandler(DataRecieved);
                _serial.Open();
                Debug.Print("Serial Opened");
            }
            catch (Exception) { Debug.Print("Exception when opening serial port"); return; }

            try
            {
                var sendData = Encoding.UTF8.GetBytes("ATZ\r\n");
                var bytesWritten = _serial.Write(sendData, 0, sendData.Length);
                if (bytesWritten != sendData.Length) { Debug.Print("Couldn't send ATZ"); }
                else { Debug.Print("ATZ Sent"); }
            }
            catch (Exception) { Debug.Print("Exeception in Send"); return; }
        }

        void DataRecieved(object sender, SerialDataReceivedEventArgs e)
        {
            try
            {
                Debug.Print("DataRecieved");
                var bytesToRead = _serial.BytesToRead;
                var bytes = new byte[bytesToRead + 1];
                var bytesRead = _serial.Read(bytes, 0, bytesToRead);

                var recieveData = new string(Encoding.UTF8.GetChars(bytes));
                if (recieveData.Substring(2, 2) == "OK") { Debug.Print("Read OK"); }
            }
            catch (Exception) { Debug.Print("Exception in DataRecieved"); return; }
            Debug.Print("Success");
        }
    }

And The result when running from VS with F5:

Serial Opened
ATZ Sent
DataRecieved
Read OK
Success

And When resetting with reset-pin+gnd:

Serial Opened
ATZ Sent

If I remove the DataRecievedEventHandler the beginning of the code and to the end of my Open method add:

Thread.Sleep(1000);
            var bytesToRead = _serial.BytesToRead;
            var bytes = new byte[bytesToRead + 1];
            var bytesRead = _serial.Read(bytes, 0, bytesToRead);

            var recieveData = new string(Encoding.UTF8.GetChars(bytes));
            if (recieveData.Substring(2, 2) == "OK") { Debug.Print("Read OK"); }
            Debug.Print("Success");

Then both VS F5-debug AND MFDeploy (reboot with pin) work:

Serial Opened
ATZ Sent
Read OK
Success

Hi Mats, When you press F5, Visual Studio does a soft reset (not the same as GND to the RESET header, but close) and then attaches the debugger. It's possible that a slight timing issue between having the debugger and not having it is bringing a bug to light (probably in the app, but it's always possible that it's a .NET MF bug). What does your main program look like (which creates the TestDebug class instance)? Is it possible that TestDebug is being disposed of or going out of scope? Chris

Hi Mats,

When you press F5, Visual Studio does a soft reset (not the same as GND to the RESET header, but close) and then attaches the debugger. It's possible that a slight timing issue between having the debugger and not having it is bringing a bug to light (probably in the app, but it's always possible that it's a .NET MF bug).

What does your main program look like (which creates the TestDebug class instance)? Is it possible that TestDebug is being disposed of or going out of scope?

Chris

Main creates a instance, executes and after that sleeps with Timeout.Infinite, so that's not a problem.

But I found a solution to the problem.
You have to attach the EventHandler after you open the serial port.

This only works with F5 in VS:

_serial.DataReceived += new SerialDataReceivedEventHandler(DataRecieved);
_serial.Open();

This works with USB-power only, after pin-reset and with F5 in VS:

_serial.Open();
_serial.DataReceived += new SerialDataReceivedEventHandler(DataRecieved);

Don't know if it's a bug or serious flaw in .NET MF documentation :-)

I think you should be able to attach a method/delegate to a event handler whenever it pleases you, not in a specific order.

Don't know if it's a bug or serious flaw in .NET MF documentation :-)

I think you should be able to attach a method/delegate to a event handler whenever it pleases you, not in a specific order.

Very interesting. I think we saw this issue once before, a long time ago. I'll put a bug in our tracking system and see if we can create a simple reproduction case...and then fix it and contribute the fix back to the .NET MF core...

Thanks for the feedback. But mostly, I'm glad that you're up and running now...

Chris

Does anyone have any idea on what's going on?

Hi Mats,

We isolated an issue which appears to be the same one as this...and patched it in the new 4.1.1 alpha 5 firmware.

If you have a chance, it would be awesome if you could give it a try and see if it behaves properly during debugging and run-time.

Thank you,

Chris

P.S. It turned out to be a bug in the .NET MF core. Long story short, uninitialized values that were being initialized during the Open() function call...but were needed when the event was being wired up. The bug has apparently been around since .NET MF 3.0. Anyway, we've fixed it and are contributing the bugfix back to the .NET MF core.