G120 is driving me nuts

I have a 25 systems with a G120 module… Sometimes they work smooth for days. But there are moments they behave weird… Cant join WiFi AP, problems using sockets to connect to a server… When this behavior shows up the only way to get rid of it is to flash the firmware and the application… Its clear to me that something must has changed in flash firmware and/or settings for what ever reason.

GHI can you supply some code to do a check on firmware changes. I was thinking of some kind of code that calculate a checksum at the startup of main, store it on SD card and every time the system is started doing a compare

Are there know issues with the modules from the first production run?

1 Like

@ andre.m - Yeah too bad

Are you sure this happens while your application runs not while deploying?

Does your app use EWR?

@ Gus - It is while the application runs fine for some days in the field. no deploy at all.

The application uses EWR. That is, during setup of the system in the field user settings are stored. This is mainly a one time process… afterwards EWR is used to load/read user settings at startup, like WiFi AP name etc. No writing is done as long nothing changed to the configuration.

After initial setup, do you set DHCP vs static or set the IP… Or anything else that writes to flash?

@ Gus - I am using DHCP but if for some reason the system can’t obtain an IP, which happens regular the method NetworkInterface.RenewDhcpLease() is called.

No write to flash at all after initial setup from managed code.

This is going to be a tough one! I bet if we test it here it will run for weeks with no issues. So, how can you help us in finding the issue?

@ Gus - I think it would be necessary to first establish if something has changed in flash.

We could run a checksum / crc test during startup and before shutdown to see if something has changed… and if, along with log data that we write to uSD we might be able to narrow things down.

Do you think that GHI can supply a small piece of checksum or crc calculation code of the important memory area’s

Isn’t this already built in through the IFU library? IIRC.

Yes, it seems to be there :slight_smile: I will implement and test it…

2 more questions:

  • Can i conclude from your questions that EWR has issues?
  • Are there RS9110 functions/methods that could affect flash?

Update:

Implemented a CRC check as one of the first methods in Main() and found that the CRC result on “SystemUpdate.SystemUpdateType.Config” changes sometimes (not always).
As a next test i removed all EWR related code and set RS9110 to static IP. But CRC on the config area keep changing (not always)

@ GHI what could be a reason that the config area changes?

1 Like

@ RobvanSchelven - Very interested in what you will find about that issue.

config is managed by many things in NETMF. It is interesting an strange to find that it changes!! It should only change when you set static IP or set DHCP. Or when you set the LCD config!

Are you sure you are not calling any of those above?

when a system is configured to use static IP, after startup it will always call
wifi.NetworkInterface.EnableStaticIP(…)

And when configured to use DHCP… it will first check if dhcp is enabled, and if not it will call enable dhcp… If the system fails to retrieve a valid IP it will call renewdhcp(…)

i don’t have/use a LCD connected to the board.

I guess that those IP related calls are the reason for config area changes,

However and just wondering… when the system is setup to use a static IP it will always be the same IP address… so this should not effect the CRC i guess though?