Is this a magnetic storm or what?.. If I put G400 into Breakout board, it always starts as COM port (but update fails, see my previous post). If I manually ground PA11 on my production board, I always end up with an unrecognized USB device, and I can’t update again 
@ Simon from Vilnius -
Disconnect all modules. I had problem when there are CAN or ENC28 connected to Socket 6,7…
and make sure disconnect PA11 from GND before running Samba
I have a G120.
I started FEZ Config, selected Firmware update, but it only showed me the Firmware update. Nothing about Tiny booter.
Not working still. Even tried on another computer. I don’t have time to waste on this anymore. [em]Is this TinyBooter update crucial or may I skip it until it is fixed?[/em]
@ Reinhard Ostermeier -
It is in Advance menu at the left corner
@ Simon from Vilnius -
I tried to reproduce you case, and I got exactly same your message. I kept PA11 connect to GND when ran Samba. So the reason mays you still keep PA11 connect to GND?
Now that you told me, I’ve checked PA11. It is shorted to GND on my G400HDR! But how? Nothing is connected, nothing is soldered on… It’s just a plain board, even without G400 module.
@ Simon from Vilnius -
I don’t know how, but at least we know why Samba doesn’t work :))
After spending a significant part of night trying to update those G400’s, I’ve started bashing G400HDR board against the table. I guess what? a 0402 sized capacitor fell off it, and now updates are working…
American and russian machines are not that different, after all. They both need a hammer to work 
4 Likes
LOL 8)
LOL … your lucky its not a 0201 probably would have never known 
Can you tell where it came from?
Actually, no. I was unable to spot a vacant capacitor position on any of the boards. It probably came from parallel universe.
LOL
But my son once bought a LED Strip as this technology was new and start playing around and after a hour he call me and show me a resistor which was molded into the plastic, but without a connection and without sense.
Maybe you also have a ‘ghost part’ on the board, fallen off another during manufactoring or misplaced which causes some problem as long as was there. falling off so easy, couldnt be correct soldered.
With best regards
Gerhard
Hello,
using this latest beta, now the Cerbuino throws this message after a 30 min of serving UDP packets: using MFDeploy to see the error…
enc28j60_lwip_recv: input alloc packet failed
enc28j60_lwip_recv: input alloc packet failed
enc28j60_lwip_recv: input alloc packet failed
enc28j60_lwip_recv: input alloc packet failed
and the board losses the IPAddress forever… a reset is a must for the Ethernet to function and this happens every 30 min or so… PS the board remains responsive LED blinking, but no Ethernet access, and cannot be detected by MFDeploy… also the Sockets are working as if nothing has happened but obviously nothing goes out of the board…
can someone shed some light on this please…
thanks.
Jay.
@ Jay Jay - You need to leave more free ram on the system. Try to force run GC periodically and print to output to Hey am idea of what is happening. Keep in mind that fragmentation is an issue on systems with small memory.
That was a good tip, I think this just solved my stability problem.
I’m using a G120 with plenty of ram, but my app is very hungry for it.
Have to collect, process and send out thousands of values via ethernet once a minute.
btw. what do you mean by " print to output to Hey am idea " ?
Same program running on the previous firmware NO Change, before it ran forever without the above issue, it had other issues but not this… so does this mean you introduced a memory leak into the new firmware?
Jay.
DHCP no longer works in Spider with built in Ethernet: Worked before this firmware 
sometimes it throws this error:
Using mainboard GHI Electronics FEZSpider version 1.0
Program Started
#### Exception System.NullReferenceException - CLR_E_NULL_REFERENCE (4) ####
#### Message:
#### Gadgeteer.Modules.Module+NetworkModule::DHCPThread [IP: 001f] ####
A first chance exception of type 'System.NullReferenceException' occurred in Gadgeteer.dll
Ethernet_J11D ERROR : DHCP Error - networking may not work
The thread '<No Name>' (0x3) has exited with code 0 (0x0).
not all the time but every now and then… but no DHCP…
Edit i’m able to reproduce the above every time in a consistent matter here is your test code: tested with Both firmware 4.2.11.0 and 4.2.11.1 and both suffer from the same issue.
//reference the following assemblies..
//GHI.Premium.Net;
//GHI.Premium.System;
var myMac = new byte[6];
var r = new Random();
r.NextBytes(myMac);
if (!Utilities.ByteArrayEquals(ethernet_J11D.Interface.NetworkInterface.PhysicalAddress, myMac))
//ethernet_J11D.Interface.NetworkInterface.PhysicalAddress = myMac;
GHI.Premium.System.Util.SetMACAddress(NetworkInterface.Built_In_Ethernet, myMac);
ethernet_J11D.UseDHCP(); //this will throw the above error...
btw assigning the MAC through the SetMACAddress or PhysicalAddress doesn’t help any…
While i’m at it, why in the world would you put SetMACAddress in this assembly GHI.Premium.System.Util and not this one GHI.Premium.Net it just doesn’t make sense if you ask me… because it requires adding an extra Assembly just for that function… hope this will be addressed in the future.
Edit: see attached image for the wireshark view hope this helps:
Another Edit: back to firmware 4.2.11.1 when I update the Mac Address to the exact MAC written on the back of my Spider using FezConfig… suddenly DHCP works… so what are we missing…?
Edit: It’s confirmed the DHCP on the Spider doesn’t work with any other MAC but the one the spider shipped with, Assigning the MAC through Code gives the above error on first try and DHCP works on reboot…So the issue is seems to be tied to the MAC…
a suggestion.
I think GHI needs to do more beta testing directly with those reporting issues to make sure the issues are resolved before releasing a public Beta hoping that everything is resolved…
You guys have us reporting issues, it means we are here to help you as much as we need your help so take advantage and set up some kind of way to work with those reporting the serious issues like Ethernet, CAN and so on…
because now it means that we have to wait another Two or Three Months, maybe SIX for another public beta that may or may NOT contain the bug FIXES… and round we go…
1 Like