Thanks Gus,
Next step is that I have to dig into the code and isolate the problem…
Will be continued.
Then I’m sure GHI took this as a non-maskable-interrupt and already has started the „search the bug routine" 
@ freeck - on socket 2 of the Cerbuino Bee there were no problems with the serial port (in conjunction with the bluetooth module, NETMF 4.2) up to a baudrate of 460800. I must admit that I made no tests for reliability in conjunction with simultaneous processing of two or more data streams.
Perhaps you can post your code with the rn171 wifi-module in a separate thread to get some hints from the community.
We will revisit this and hopefully improve. I just do not have a quick answer, sorry.
I am afraid there are two separate issues.
The buffer overrun error, or whatever you call it , and problems communicating with the Wifly module via the serial port.
1: I plugged the Wifly on a XBEE-to-USB-serial adapter, and noticed that there are characters lost in the response of the Wifly. See image RN171ping.
The fifth line is totally corrupted…
2: then I attached the Wifly on Cerbuinobee, I also attached a serial monitor. See output on image RN171pingCerbuino…As you can see ;D , the serial monitor receives all the output of the “join” command sent to the Wifly, but the Cerbuino seems to loose a few characters (see response “Rec line: HCP” which should be “Rec line: DHCP”).
Help, help, I am out of options , perhaps somebody has a clou. Is the timing of the uart of the Wifly perhaps out of spec?
PS: btw I also tested a loopback communication connecting Tx and Rx of the Cerbuino , which show no anomalies.
@ freeck -
this seems not to be an issue of Cerbuino Bee or RN171.
with my Setup it works without data corruption.
https://www.ghielectronics.com/community/codeshare/entry/927
@ RoSchmi - thanks for your input.
The strange thing is that I can reproduce some of the anomalies using a xbee to usb adapter, so that indeed excludes the cerbuino and the driver…
Then I suspect the configuration settings of the 171… I will reload the firmware and see what happens…
Will be continued…
PS concerning the latest source code ; I will look into it. I was wondering whether it is possible to add/ include the XBEE socket as a gadgeteer socket…
Hi,
I would suggest to open a new thread for this issuse. It seems that it has not so much to do with the original question of this thread.
I agree, as soon I resolved this issues I will put it on another thread.
@ freeck - Be careful to RN171 module current draw !! 1 year ago I had lot of trouble becouse using WPA security and joining wifi the module become really unstable. I faced same issue on a Cobra II board. Using WEP security the problem disappeared.
I was using GHI gadgeteer module for XBee. I own two of this module: one module has no issue with both (RN171 and XBee), the other worked with XBee and NOT with wifly. I recently (partially) solved the issue after fw 4.00 was released by Microchip (now latest fw is 4.41, but I haven’t tested).
Here you can find firmwares:
ftp://rn.microchip.com/public/
You will require user and password you can find on the wifly manual.
RS232 buffer overrun on Cerberus when network is open
Stephs issue, the buffer overruns still occur in SDK Version 2014 R3
Thanks RoSchmi for having tested so quickly !
It would have been great if this had been fixed, but I must admit it has been discovered late in the cycle.
A question to GHI : do you release intermediates patches or will we have to wait for R4 ?
I was on occupied by other project, but as USB host is available, I’ll try with a USB serial port, hoping it will leave enough ram for the rest of the application.
Not tried USB serial yet, but I had the possibility to try on a cobra eco : same problem :’(