Main Site Documentation

G120 Firmware Hotfix v4.2.9.10


#1

We have solved two very difficult bugs, and would like to provide a new firmware to the community.

We believe that we have finally solved the DCHP/Socket creation error with G120.
We have corrected the issue with sending and receiving data over serial simultaneously.

We would like to invite you to test this firmware, and give us any feedback that you have. If you were affected by either of these issues, please let us know if the issues were corrected.

The firmware files can be found at: http://www.ghielectronics.com/downloads/Beta/G120%20Firmware%20Hotfix%20v4.2.9.1.zip


#2

Thank you guys! I’ll give it a try tonight.


#3

I am happy to hear and really appreciate the hard work you all did… Thanks !! I will check tonight


#4

My low baud rate serial issue appears solved. THANK YOU!


#5

Running the GHI test app for DHCP from http://www.tinyclr.com/forum/topic?id=10855&page=8#msg111505, using the new 4.2.9.1 firmware, doesn’t seem to have fixed my wifi DHCP issue.

Here’s what I did.
Extracted 6x files from zip
Used G120 Updater to update Cobra II wifi board; used 4.2.9.0 tinybooter, and 4.2.9.1 firmware, used "erase all"
Opened existing test application; F5

[quote]Found debugger!
Create TS.
Loading start at a0e856b0, end a0e9ce0c
Assembly: mscorlib (4.2.0.0) Assembly: Microsoft.SPOT.Native (4.2.0.0) Assembly: Microsoft.SPOT.Hardware (4.2.0.0) Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1) Assembly: Microsoft.SPOT.Security.PKCS11 (4.2.0.0) Assembly: System.Security (4.2.0.0) Loading Deployment Assemblies.
Attaching deployed file.
Assembly: Microsoft.SPOT.IO (4.2.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Graphics (4.2.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.TinyCore (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.System (4.2.9.0) Attaching deployed file.
Assembly: Cob2DHCPTestGHI (1.0.0.0) Attaching deployed file.
Assembly: Gadgeteer (2.42.0.0) Attaching deployed file.
Assembly: GHI.Premium.Net (4.2.9.0) Attaching deployed file.
Assembly: System.IO (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.IO (4.2.9.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Net (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.Hardware (4.2.9.0) Attaching deployed file.
Assembly: GHIElectronics.Gadgeteer.FEZCobra_II (1.1.1.0) Attaching deployed file.
Assembly: GHI.Premium.Hardware.G120 (4.2.9.0) Resolving.
GC: 1msec 438384 bytes used, 6901284 bytes available
Type 0F (STRING ): 24 bytes
Type 15 (FREEBLOCK ): 6901284 bytes
Type 17 (ASSEMBLY ): 26868 bytes
Type 1E (BINARY_BLOB_HEAD ): 411420 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
GC: performing heap compaction…
Ready.
RS9110 firmware version Number is 4.4.5
RS9110 driver version Number is 4.4.5
Found 1 networks
Scan result 0 = InTheBay
Sleeping…
Wireless is: Connected
SSID: InTheBay
WiFi Channel number: 1
Wireless Network Type: Access Point
MAC Address: 00:04:ED:1D:A4:25
RSSI: -68dB
Wireless Security Mode: WPA2
[/quote]

Stays this way, never triggers wifi_NetworkAddressChanged()

On the router I can see the device has a pending lease on an IP address, it’s lease time shows somewhere around 120 seconds, but the lease time keeps resetting so I assume that it’s requesting it over-and-over but never accepting the offer.


#6

We surly fixed a bug so there maybe another bug. What is your router model number?


#7

Billion 7404VNPX


#8

Okay, after several hours of exhaustive testing, I’m still happy with the hotfix. However, I have noticed an oddity when performing full duplex serial communication, in that COM3 (and only COM3) drops a few bytes here and there. All other ports are perfect.

Broadly speaking, here’s what you can do to test (requires two G120s again):

Using all 5 COM ports, have one G120 send data to another G120, and at the same time have the second G120 send data to the first one, so that all COM ports on both units are performing full-duplex communication with their sister port on the other. I recommend setting all ports to a fast baud rate like 115200.

Packet size should be the same for all ports and should be large enough that all ports are active most of the time, but not so large that the channel capacity is exceeded. For my test I had each port throwing 1152 bytes at each other.

I’ve noticed that about every 10 thru 25 seconds, COM3 [em]on one of the units [/em]drops a few bytes here and there. COM3 on the other unit does not. So it appears to be not only COM3-specific, but also direction specific to one G120. All other ports transfer data at 100% accuracy.

Dunno if there’s something different about COM3 under the hood. And this particular behavior doesn’t bother me, since I primarily use half-duplex communication, but it may be an irritant to someone who needs accurate full-duplex serial. It may or may not be worth checking out.


#9

There is nothing special about COM3.


#10

I went to buy one but looks like this is an Australian only router, found on ebay for $300! Hopefully someone else can report a local router that fails.


#11

might be worth while to calculate peak com transfer rates. at 115200 per port might be close to capacity.


#12

@ Mike - Yup, channel capacity is definitely a concern. I’m perfectly happy with this fix. It’s just one of those strange little things that appeared during torture testing. I’d consider it low priority (or no priority).


#13

If there’s anything you can point me at to help diagnose this, happy to do so. I’m always willing to do what I can (although wifi will stretch what I can do, I think)


#14

@ Brett - Maybe try a different router if you have access to one? Preferable one that is available to us in USA :slight_smile:


#15

I don’t have access to a different wifi router unfortunately :frowning:

This is my first G120 based device; is there a need to have an Assign Network Stack in the wifi code Edit: it is there, just can’t read :slight_smile:

Is there a standard G120+ENC28 test app you’d like me to use? Yes, I can then grab network traces to see the comms…


#16

I have access to a phone though

[quote]RS9110 firmware version Number is 4.4.5
RS9110 driver version Number is 4.4.5
Found 1 networks
Scan result 0 = Poundy’s Lumia
Wireless is: Connected
SSID: Poundy’s Lumia
WiFi Channel number: 11
Wireless Network Type: Access Point
MAC Address: 50:2D:1D:5B:8D:F6
RSSI: -50dB
Wireless Security Mode: WPA2
Sleeping…
New address for the Wireless Network Interface
Is DhCp enabled: True
Is DynamicDnsEnabled enabled: False
NetworkInterfaceType 71
Network settings:
IP Address: 192.168.33.51
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.33.1
Number of DNS servers:1
DNS Server 0:192.168.33.1
------------------------------------------------------[/quote]

So, it’s specific to my router. I’m going to try to dig into whether I can turn up logging on dhcp to see if there’s any clues


#17

DHCP / RS9110 on G120 is working well now on Cisco EPC3925 and a Chinese brand portable router MP01… Both gave problems with the previous firmware releases.

10 tests hard-reset G120. Result: 10 x IP within 10 seconds
10 tests new deploy Debug mode from VS2010. Result: 10 x IP with 10 seconds
10 tests Turn power Off/ON G120. Results 10 x IP within 10 seconds.

With the previous firmware i also saw more Join exceptions when testing in debug mode from within VS2010. This seems to be resolved too.

10 test with already heavy traffic on the same wifi channel/router resulted in 2 Join exceptions and 2 no IP releases… But thats not an issue right now and can be resolved to place the Join and enableDHCP() in a retry loop.

I think i can now change my routers SSID in “I am happy again”

Thanks Guys @ GHI


#18

@ andre.m - sorry, I don’t have isc running and even not any linux system. To test i can setup one if you like.


#19

@ andre.m - Sorry for the confusion… I meant the same behavior… 1 x IP next after Reset no IP


#20

@ andre.m - Yes, i hope for you too… Have you tried to put enableDhcp() in a loop when after X time still not received an IP…