NETFW = 4.2
J11D connector - wired ethernet
Good 5v PSU
MAC = Sticker on module
I have spent many hours trying to get a very simple UDP socket to listen and respond to a client using mimimal code at this point. In the emulator everything works fine and my client on a different PC can talk to the emulator without problems at all. When I load the code into the Spider again things seem normal and the Spider receives the UDP message from the client and responds with the 4 byte response message. At this point it seems things are very wrong but no errors are generated at all. Here is what happens:
The Spider listens for a UDP incoming message (fine it comes and content looks good).
The Spider responds with SentTo(…) with 4 bytes (all sems fine, SendTo reports 4 bytes sent).
I can see the UDP packet with WireShark on my client machine but the 4 byte data is corrupt (every time and the bytes could contain any rubbish).
My C# client code never see’s any data arrive at all.
The source, destination and port numbers all seem fine in WireSharks capture.
I also have an EMX dev board and loaded the same project on that (NETFM 4.0.1). Now everything works absolutely fine within a couple of seconds.
Either there is something fundamental I am not doing for the FEZ Spider, it is faulty or NETFM 4.2 is buggy, I just don’t know.
I have extracted some code from my project as requested. I am trying to use the minimum code at the moment just to prove everything. Like I mentioned, the problem is with data corrupted coming out of the Spider (SendTo) and it all works fine in the emulator and on an EMX dev board with 4.0.1 NETMF.
m_server = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
m_localEndPoint = new IPEndPoint(IPAddress.Any, 6213);
m_remoteEndPoint = new IPEndPoint(IPAddress.Any, 0);
if (m_server.Poll(-1, SelectMode.SelectRead))
byte buffer = new byte[m_server.Available];
m_server.ReceiveFrom(buffer, ref m_remoteEndPoint);
IPEndPoint ipe = (IPEndPoint)m_remoteEndPoint;
byte response = new byte;
response = 45;
response = 77;
response = 45;
response = 77;
The response array is just test data to prove things.
Ok Architect thanks, couldn’t see the button though.
Here is a pic of the Wireshark screen with the data selected. The data changes between calls so its random corrupt data. From what I can tell the UDP packet is ok to an extent.
I just updated the firmware on my EMX dev board to 4.2.4 (from 4.0.1) and now the same code has the problem on this board too. From this I think there is no hardware issue with the Spider board. It seems there is a problem with the firmware as I can demonstrate it consistently.
Thanks. I am trying to develop a product with the EMX but I am spending so much time on basic issues like this. My confidence is this type of product is decreasing rapidly right now. I would have been quicker to get a PIC ethernet device up and running.
UDP sending works without corruption in 4.0.1 but is corrupt on 4.2.4. Tested with an EMX gadgeteer and EMX dev board. Both show the same problem. My impression is that 4.2.4 is the problem.
It might also explain why the static/dhcp side of things does not feel right to me, sometimes the dhcp works and sometimes not, it’s all a bit frail.
Yes I think so. I have installed v4.1 on my Gadgeteer and EMX dev board and all is good. My Android devices and PC’s can all talk to the EMX stuff now but I don’t want to be stuck on an old release :-(.
How do GHI get to take a look, do we rely on them reading these posts?
ok I will try the new SDK. Is this 4.3 or an update to 4.2?
I am really trying to adopt the EMX and NetMF for serious product development. How can I be confident that fundamental mechanisms like basic tcp and udp work properly. The problem is the time required to sort things like this out.
Should I only consider netmf as a hobby type development rather than serious product development?
4.2 is in beta so issues are somewhat expected. If your product ships before January then 4.1 is the way to go.
GHI does multi-million dollar in the sale of NETMF devices to companies/professionals around the world. Yes it is very much developer friendly that it is used by non-professionals but this does not mean NETMF quality or GHI product quality and support are anything less that what you would expect from similar offers/companies.