Diable RS9110 firmware update

Hi all,

I’m testing RS9110 and on a number different situations the RS9110 decides that he needs a firmware update and locks up the thread for 60 seconds while i just want to handle the exeption…

Is there a way to disable this functionality?

Bellow is a example:

RS9110 firmware version Number is 4.4.5
RS9110 driver version Number is 4.4.5
#### Exception System.Exception - 0xffffffff (3) ####
#### Message:
#### GHI.Premium.Net.RS9110Helper::QueryMACAddress [IP: 0000] ####
#### GHI.Premium.Net.RS9110Helper::get_MacAddress [IP: 0003] ####
#### GHI.Premium.Net.WiFiRS9110::RunFirmware [IP: 007e] ####
#### GHI.Premium.Net.WiFiRS9110::Intialize [IP: 0007] ####
#### Ethernet.Ethernet::Connect_Wifi [IP: 001e] ####
#### IRC.Program+ExecTheseLines::Run [IP: 00d2] ####
#### IRC.Program::ExecLines [IP: 0014] ####
#### IRC.Program::DIn02_OnInterrupt [IP: 0139] ####
#### Exception GHI.Premium.Net.NetworkInterfaceExtensionException - 0x00000000 (3) ####
#### Message:
#### GHI.Premium.Net.WiFiRS9110::RunFirmware [IP: 0090] ####
#### GHI.Premium.Net.WiFiRS9110::Intialize [IP: 0007] ####
#### Ethernet.Ethernet::Connect_Wifi [IP: 001e] ####
#### IRC.Program+ExecTheseLines::Run [IP: 00d2] ####
#### IRC.Program::ExecLines [IP: 0014] ####
#### IRC.Program::DIn02_OnInterrupt [IP: 0139] ####
Start Updating WiFi module firmware:
This might take up to 1 minute
0 Sec
1 Sec
2 Sec

49 Sec
RS9110 firmware update completed
RS9110 firmware version Number is 4.4.5
RS9110 driver version Number is 4.4.5
#### Exception System.Exception - 0xffffffff (3) ####
#### Message:
#### GHI.Premium.Net.RS9110Helper::QueryMACAddress [IP: 0000] ####
#### GHI.Premium.Net.RS9110Helper::get_MacAddress [IP: 0003] ####
#### GHI.Premium.Net.WiFiRS9110::RunFirmware [IP: 007e] ####
#### GHI.Premium.Net.WiFiRS9110::Intialize [IP: 002a] ####
#### Ethernet.Ethernet::Connect_Wifi [IP: 001e] ####
#### IRC.Program+ExecTheseLines::Run [IP: 00d2] ####
#### IRC.Program::ExecLines [IP: 0014] ####
#### IRC.Program::DIn02_OnInterrupt [IP: 0139] ####
A first chance exception of type ‘System.Exception’ occurred in GHI.Premium.Net.dll
An exception of type ‘System.Exception’ occurred in GHI.Premium.Net.dll and wasn’t handled before a managed/native boundary

There is no way to disable updating the firmware. Your stack trace shows an error in RunFirmware though, not UpdateFirmware.

did i say i have a error in the update :open_mouth:

I just wanted to avoid this uneeded updates that are locking the thread for 60 seconds :wink:

But if it’s not possible then we have handle this in another way.

If the right firmware is not loaded then the device will simply not function properly.

Isn’t David’s point that he runs the same hardware a number of times, and some times it doesn’t detect that a firmware is needed, and sometimes it does, when really the hardware hasn’t changed ? As the text in his debug says, the firmware was 4.4.5 before it detected an update was needed, and after it reportedly applied it is still 4.4.5 which is obviously a mis-reported firmware version mismatch (and totally unnecessary step)

@ Brett - Yep, for some errors the RS9110 just is programmed to update the firmware but there is no need for it, we are in test faze and try to sabotage as much possible points to see how the behavior is.

In many cases the RS9110 is locking the thread for 60 sec and will still have a error because firmware update is not needed.

And this is exactly why i ask if it’s possible to disabling this and handle the firmware update manual.

And the correct firmware IS loaded all the time :open_mouth:

It looks like there are stability issues around MacAddress that are the trigger for this firmware updates.

I have:
#### Exception System.NullReferenceException - CLR_E_NULL_REFERENCE (3) ####
#### Message:
#### GHI.Premium.Net.NetworkInterfaceExtension::UpdateMacAddress_Helper [IP: 0000] ####
#### GHI.Premium.Net.NetworkInterfaceExtension::UpdateMacAddress [IP: 0008] ####
#### GHI.Premium.Net.WiFiRS9110::RunFirmware [IP: 0081] ####
#### GHI.Premium.Net.WiFiRS9110::Open [IP: 0014] ####

and:
#### Exception System.Exception - 0xffffffff (3) ####
#### Message:
#### GHI.Premium.Net.RS9110Helper::QueryMACAddress [IP: 0000] ####
#### GHI.Premium.Net.RS9110Helper::get_MacAddress [IP: 0003] ####
#### GHI.Premium.Net.WiFiRS9110::RunFirmware [IP: 007e] ####
#### GHI.Premium.Net.WiFiRS9110::Open [IP: 0014] ####
#### IRC.Program+ExecTheseLines::Run [IP: 00d2] ####


        private void RunFirmware()
        {
            this.Reset();
            try
            {
                try
                {
                    RS9110Helper.RS9110_InitContinuations_helper();
                    RS9110Helper.OnEvent += new RS9110HelperEventHandler(this.RS9110Helper_OnEventRunFirmware);
                    WiFiRS9110._waitOnCardReady.Reset();
                    try
                    {
                        RS9110Helper.InitSPIInterfaceRequest();
                        RS9110Helper.SetBootloadOption(0);
                    }
                    catch
                    {
                        throw new NetworkInterfaceExtensionException(NetworkInterfaceExtensionException.ErrorCode.HardwareCommunicationFailure);
                    }
                    bool flag = WiFiRS9110._waitOnCardReady.WaitOne(5000, true);
                    RS9110Helper.OnEvent -= new RS9110HelperEventHandler(this.RS9110Helper_OnEventRunFirmware);
                    if (!flag)
                    {
                        throw new NetworkInterfaceExtensionException(NetworkInterfaceExtensionException.ErrorCode.HardwareCommunicationTimeout);
                    }
                    Debug.Print(string.Concat("RS9110 firmware version Number is ", RS9110Helper.FirmwareVersionNumber));
                    Debug.Print("RS9110 driver version Number is 4.4.5");
                    if (RS9110Helper.FirmwareVersionNumber != "4.4.5")
                    {
                        this.Reset();
                    }
                    RS9110Helper.BandRequest(0);
                    Thread.Sleep(1);
                    RS9110Helper.InitRequest();
                    Thread.Sleep(1);
                    try
                    {
                        base.UpdateMacAddress(RS9110Helper.MacAddress);
                    }
                    catch
                    {
                        this.Reset();
                        throw new NetworkInterfaceExtensionException(NetworkInterfaceExtensionException.ErrorCode.HardwareFirmwareCorrupted, "UpdateFirmware() must be called to upload the firmware");
                    }
                }
                catch
                {
                    throw;
                }
            }
            finally
            {
                RS9110Helper.RS9110_UninitContinuations_helper();
            }
        }

I have a feeling i need to dig down from “base.UpdateMacAddress(RS9110Helper.MacAddress);”

This is after the firmware version check, i dont think just anny error should trigger the firmware update.

Could you create a small program that throws those exceptions?

I have a look at this next week to see if can build a minimal program that simulate this behavior. If i go back to the absolute bare minimum in a clean console application it’s 100% error free but if i merge the same code in my main project then i have instability: like 60-70% off the open commands will trigger the firmware update.

;D

Problem solved after 3 days testing and trying to reproduce this in a sample program.

My solution is a collection off 5 different projects and in the project where Wi-Fi is implemented i had a reference to GHI.Premium.Net 4.2.10.0 and the main project had a reference to GHI.Premium.Net 4.2.11.1 :wall:

Lost allot of time, learned allot but happy it’s running stable right now :smiley:

Interesting :think:
I thought the linker would check versions stuff when deploying.

it does… if it’s the other way around: 4.2.10.0 in the main project and 4.2.11.1 and the sub…
(it’s there that i noticed it and went checking all the references…)

Because we still have situations where the firmware update is executed (and needed) we are now shelling the open command in a new low prio thread and this is working just fine :slight_smile:

All other events keep running and communication is not bothered by the firmware update.

Maybe this could be useful for other users :wink: