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:
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.
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.
@ 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.
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.