Xbee module - DataReceived not firing except when debugging

Archive
1

HI,

Using the June 22 beta, but with a NETMF 4.1 project with Spider, I’m finding the Xbee module’s DataReceived event will only fire if I am debugging over USB, if I stop debugging, pull out the USB cable and plug it in again (so USB is powering the Spider but we’re not in debug mode), I can see my Xbee’s RX light come on when data is received, but the event itself doesn’t fire. Start debugging again, the event fires just fine. If I add a timer tick to the project and periodically poll the value of xBee.SerialLine.BytesToRead, I can see it build up as data is received, and indeed if I call my DataReceived event handler directly from my periodic polling timer, I can kludge the system into dealing with the data, it can be read fine so long as the system knows there’s something to read - but of course I shouldn’t have to use such a workaround, there’s clearly a weird problem with this event and the debugging.

Just in case you were going to ask about firmware / MFDeploy:


Pinging... TinyCLR
HalSystemInfo.halVersion:               4.1.2821.0
HalSystemInfo.halVendorInfo:            Microsoft Copyright (C) Microsoft Corporation.  All rig
HalSystemInfo.oemCode:                  255
HalSystemInfo.modelCode:                0
HalSystemInfo.skuCode:                  65535
HalSystemInfo.moduleSerialNumber:       FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
HalSystemInfo.systemSerialNumber:       FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
ClrInfo.clrVersion:                     4.1.2821.0
ClrInfo.clrVendorInfo:                  Microsoft Copyright (C) Microsoft Corporation.  All rig
ClrInfo.targetFrameworkVersion:         4.1.2821.0
SolutionReleaseInfo.solutionVersion:    4.1.8.0
SolutionReleaseInfo.solutionVendorInfo: GHI Electronics, LLC
SoftwareVersion.BuildDate:              Dec 22 2011
SoftwareVersion.CompilerVersion:        410561
FloatingPoint:                          True
SourceLevelDebugging:                   True
ThreadCreateEx:                         True
LCD.Width:                              320
LCD.Height:                             240
LCD.BitsPerPixel:                       16
AppDomains:                             True
ExceptionFilters:                       True
IncrementalDeployment:                  True
SoftReboot:                             True
Profiling:                              False
ProfilingAllocations:                   False
ProfilingCalls:                         False
IsUnknown:                              False

RorschachUK

2

I see nobody replied. Can it be because you subscribe to the event and then open the port? (known issue).

If not, please show your code.

3

Hi, you’re right I’m surprised no replies, if only because it’s so blatantly behaving differently in debug mode than when not debugging, you’d think that would be an easy thing to reproduce and find.

Nope to your question though - I’m opening the port before subscribing, the relevant snippet from ProgramStarted currently reads:


            try
            {
                xBee.Configure(9600, GT.Interfaces.Serial.SerialParity.None, GT.Interfaces.Serial.SerialStopBits.One, 8);
                xBee.SerialLine.Open();
            }
            catch (Exception ex)
            {
                DebugWindow.AddToLog(ex.Message);
            }
            xBee.SerialLine.DataReceived += new GT.Interfaces.Serial.DataReceivedEventHandler(SerialLine_DataReceived);

The exception is never called, whether debugging or not, the DataReceived event fires OK if debugging and doesn’t if powered but not debugging, the data does arrive, the Xbees are working fine, if I setup a timer to poll the state of xBee.SerialLine.BytesToRead I can see the number rise without the DataReceived event firing (unless debugging), I can even read that data just fine, it’s only the event that isn’t happening when powered but not debugging.

NB in the code snippet above, the try/catch and configure were added to try to track down the problem, still behaves the same if they’re omitted.

RorschachUK

4

One more thing to try.

Put a Thread.Sleep(200) right after you open SerialLine.

5

Good plan, plausible-sounding idea, just tried it though, made no difference - sorry!

6

Ok, found the problem.

The Serial class implementation inside Gadgeteer core subscribes to the event first in the constructor of the Serial class. So by the time you call Open you are already subscribed. That is the issue.

To fix this you will need to do the change and recompile Gadgeteer core. The source code is on codeplex.

7

Good catch. So is that in MS’s code, or GHI’s? Sounds like it’s likely to affect all use of serial connections in that build, not just my use of Xbees.

8

That’s MS code. This issue was resolved in .NET MF 4.2 so when you upgrade your Spider you will be ok (I think there is no 4.2 for Spider yet, maybe beta). Or you can do as Architect suggests, get the gadgeteer source code from codeplex, change this subscribing and recompile.

9

@ Architect - Above and beyond the call of duty, think GHI should pay you a retainer :wink:

10

@ Justin - Thanks :slight_smile:

@ RorschachUK - Yes, everything that uses Serial from core is affected. Another option is to take Serial class from Gadgeteer core and put it into the driver project. You can rename it or “hide” it in the driver’s namespace, fix the issue and use that implementation instead of the one from the core. That way you only need to rebuild the driver.

11

So am I right in saying that this is fixed in 4.2 for all serial devices? I was seeing the same issue with a serial RFID reader (ID-12). Worked perfectly during debug but not when powered but no debug.

12

Did you see it in 4.1 or 4.2?

13

4.1 haven’t tried 4.2 yet as I decided to wait for full spider support in 4.2

14

I checked the 4.2 gadgeteer code, and the event registration still occurs in the constructor of the serial port. the registration needs to be moved to the open method.