LTE M1 cellular firmware updating to Gpy stucks, says, Waiting for updater to load...
-
While updating the firmware of LTE CAT1 in my Gpy modem (that my lab recently purchased from core electronics) for the very first time, I am repeatedly stuck in that notification, 'waiting for updater to load..'
I have loaded my SD card with the updater.elf file along with CATM1-39529.dup file.
Where I am making mistake? Anyone any insight please, much much appreciated.>>> sqnsupgrade.run('/sd/CATM1-39529.dup', '/sd/updater.elf') <<< Welcome to the SQN3330 firmware updater [1.2.3] >>> >>> GPy with firmware version 1.18.2.r2 Attempting AT auto-negotiation... Session opened: version 1, max transfer 2048 bytes Sending 429340 bytes: [########################################] 100% Waiting for updater to load...In short, what I have done:
-
Basically, I followed the guideline video by Chris as here, Pycom GPy & FiPy Cellular LTE Firmware Update, Core Electronics.
-
So, I updated 3 firmware, as below:
i. Firmware for the Expansion Board, following Expansion 3.1 Firmware Update. Outcome as,
a) Device:
b) Firmware confirmationC:\Users\hasanf\Downloads\IoTresearch\pycom>dfu-util-static.exe -D pansion31_0.0.11.dfu dfu-util 0.9 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2016 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ Match vendor ID from file: 04d8 Match product ID from file: ef99 Opening DFU capable USB device... ID 04d8:ef99 Run-time device DFU version 0100 Claiming USB DFU Runtime Interface... Determining device status: state = dfuIDLE, status = 0 WARNING: Runtime device already in DFU state ?!? Claiming USB DFU Interface... Setting Alternate Setting #0 ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing DFU mode device DFU version 0100 Device returned transfer size 64 Copying data from PC to DFU device Download [=========================] 100% 16384 bytes Download done. state(2) = dfuIDLE, status(0) = No error condition is present Done!
ii. Following this link I updated Firmware Gpy Firmware update on Expansion 3.1, And the outcome is below:
iii) Then I follow this link Pycom GPy & FiPy Cellular LTE Firmware Update, Core Electronics to update the Cellular LTE M1 firmware. The only thing I made change is the following code.
sqnsupgrade.run('/sd/FIPY_GPY_CATM1_33988.dup', 921600)
This code gives an error:
<<< Welcome to the SQN3330 firmware updater [1.2.3] >>>
>>> GPy with firmware version 1.18.2.r2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "sqnsupgrade.py", line 908, in run
File "sqnsupgrade.py", line 178, in check_files
File "sqnsupgrade.py", line 152, in __check_file
TypeError: 'int' object is not subscriptableThus I followed the README.md file and use the updater.elf as
sqnsupgrade.run('/sd/CATM1-39529.dup', '/sd/updater.elf')
However, this gives the final look likes,>>> sqnsupgrade.run('/sd/CATM1-39529.dup', '/sd/updater.elf') <<< Welcome to the SQN3330 firmware updater [1.2.3] >>> >>> GPy with firmware version 1.18.2.r2 Attempting AT auto-negotiation... Session opened: version 1, max transfer 2048 bytes Sending 429340 bytes: [########################################] 100% Waiting for updater to load...Once I heating Clrt+C, gives,
>>> sqnsupgrade.run('/sd/CATM1-39529.dup', '/sd/updater.elf') <<< Welcome to the SQN3330 firmware updater [1.2.3] >>> >>> GPy with firmware version 1.18.2.r2 Attempting AT auto-negotiation... Session opened: version 1, max transfer 2048 bytes Sending 429340 bytes: [########################################] 100% Waiting for updater to load... Code download failed, aborting! Unable to load updater from /sd/updater.elfExtra look:
- My SD card snap:
- I understand that for the very first time of update, i must use recovery mood, ie, this command
sqnsupgrade.run('CATM1-39529.dup', 'updater.elf')Since I am trying desperately, I tried upgrade as well and ended with following,
>>> import sqnsupgrade >>> sqnsupgrade.run('/sd/upgdiff_38638-to-39529.dup') <<< Welcome to the SQN3330 firmware updater [1.2.3] >>> >>> GPy with firmware version 1.18.2.r2 Attempting AT wakeup... Session opened: version 1, max transfer 8192 bytes Sending 461955 bytes: [########################################] 100% Waiting for modem to finish the update... This might take several minutes! <<<=== DO NOT DISCONNECT POWER ===>>> Upgrade failed with result failure[diffUpgrade,226] Patch didn't apply! Please check your firmware file(s)NEW INSIGHT WITH FIPY:
Experiencing exactly the same scenario with brand new Fipy module with Expansion board 3.
This time all I have noticed as:
for the very first attempt of Cellular Firmware up-gradation outcome,>>> import sqnsupgrade >>> sqnsupgrade.run('/sd/CATM1-39529.dup', '/sd/updater.elf') <<< Welcome to the SQN3330 firmware updater [1.2.3] >>> >>> FiPy with firmware version 1.18.2.r2 Attempting AT wakeup... Session opened: version 1, max transfer 8192 bytes Sending 55570 bytes: [########################################] 100% Attempting AT auto-negotiation... ERROR sending AT command... no response? b'' AT auto-negotiation failed! Exiting. Unable to load updater from /sd/updater.elfIt dealt with, transfer 8192 bytes and sends 55570 bytes before crashing.
I can ensure that the updater.elf was in the SD card,>>> from machine import SD >>> sd = SD() >>> os.mount(sd,'/sd') >>> os.listdir('/sd') ['System Volume Information', 'CATM1-39529.dup', 'updater.elf', 'upgdiff_33080-to-39529.dup', 'upgdiff_38638-to-39529.dup', 'test.txt']Following on, every other attempts gives the result as,
>>> import sqnsupgrade >>> sqnsupgrade.run('/sd/CATM1-39529.dup', '/sd/updater.elf') <<< Welcome to the SQN3330 firmware updater [1.2.3] >>> >>> FiPy with firmware version 1.18.2.r2 Attempting AT auto-negotiation... Session opened: version 1, max transfer 2048 bytes Sending 429340 bytes: [########################################] 100% Waiting for updater to load...Waiting for updater to load... that I am dealing with!
Important here that, the transferring byte size is small, 2048 bytes always and sends 429340 bytes. with respect to the very first attempt of transfer 8192 bytes and sends 55570 bytes !So, what's going on?
How can I erase and clean the Firmware for redoing again?
-
-
@reidfo The issue is that an unsupported band is being used by the modem and causes it to crash and reboot. It's a bit more involved but that is the gist. I got a revised firmware that appears to have resolved it. I suppose I could PM the fw. Not sure if pycom would frown upon sharing. I would expect this is resolved in the next release after 1.18.2.r3.
-
@panda Have you had any further progress on this? I haven't seen anything from Pycom on this issue. Your post finally seems to confirm the behavior I am seeing. This and the enormous power consumption by GPy/Expansion board has me investigating modules from another manufacturer.
-
Pycom was very helpful today and we determined that the modem is crashing when attaching. We determined this by looking at the debug output directly from the modem (soldering required).
At this point the only criteria to render a modem as non-functional is to perform a firmware update from the default 33080. Still not clear what is specific to this batch of GPys I have that this is an issue. Hardware related? Sequeans firmware issue? Still not clear. I have GPy modules purchased last year and they are fine.
I would be happy to use the default 33080 if I could, but I have no connection stability and excess module heat running the older firmware.
-
I still believe my issues are related to the modem and not the Pycom firmware. I have already tried downgrading with no success. On the modules I have that work they connect reliably.
-
@reidfo You are right. I solved that issue a couple of days ago by downgrading the Pycom firmware to 1.18.2 (Fipy). Cause, I have had similar problem with Fipy as well. So, the latest firmware is broken!
Attention to @panda @BorbonJugglerFor Gpy: Firmware Gpy
For Fipy: Firmware Fipy
-
Most of my modules (GPy) will not attach. Some will only on AT&T, some only on Verizon, some not at all. I have tried multiple Cat-M carriers but have not had any reproducible success. Support ticket and questions here remain unanswered.
-
@borbonjuggler I saw that too but on modules that work I dont see this. Only on the modules that will not attach. They are also unable to see towers. I question if it is actually scanning.
-
I just had it from before the latest was released. I have found some GPys work fine and others don't. Same sim, same firmware, same code. But different results. I have a ticket with Pycom but still no word on this. I have 75 units sitting here waiting to be updated.
-
@panda In the AT Commands Manual they said that is :
+SYSSTART URC indicates that the ME has started (or restarted after a
^RESET) and is ready to operate again.
+SHUTDOWN URC indicates that the ME has completed the reset procedure
and will restart.
The unsolicited command +SYSSTART is issued at each start or reboot. It
signals that the device is ready for operation.
-
@reidfo Hello I am having the same problem with my boards, where did you find the FW ? Have you tested the modem capabilities ? I meant have you manage to connect to the network of your cellular carrier. It's quite frustrating all this process.
-
So it appears that after the upgrade these modems are constantly restarting. If I run the following:
import time from network import LTE lte = LTE() time.sleep_ms(1000) lte.attach(apn='hologram') while lte.isattached() == False: r = lte.send_at_cmd("AT+CSQ").split('\r\n') print(r) time.sleep_ms(1000) print("Attached!")The output is as follows:
['', '+CSQ: 99,99', '', 'OK', ''] [''] ['', '+SYSSTART', ''] ['', '+CSQ: 99,99', '', 'OK', ''] [''] ['', '+SYSSTART', ''] ['', '+CSQ: 99,99', '', 'OK', ''] [''] ['', '+SYSSTART', ''] ['', '+CSQ: 99,99', '', 'OK', ''] [''] ['', '+SYSSTART', '']Note the SYSSTART every few seconds. Does this give anyone a clue as to what the issue is? I have tried downgrading the modem firmware. No luck. Same behavior. Then tried upgrading using the both the full .dup files and diff files. Nothing works.
-
Update:
While the update executes successfully with the older fw, the modems are actually not functioning. They hang periodically and refuse to attach.
I used the following according to the docs on a new device (never updated before):
sqnsupgrade.run('/sd/deploy/lte_firmware/upgdiff_38638-to-39529.dup', debug=True)I just read here: https://github.com/pycom/pycom-libraries/tree/master/lib/sqnsupgrade
"When using differential upgrade packages (ex: upgdiff_XXXX-to-XXXX.dup) you CANNOT use updater.elf file."
So which is it? How to I fix this?
Here is the info() for the modem. I tried 2 others with the same result. They will not attach and they are hanging (blocking code) for seconds at a time.
Here is the info() after update:
<<< Welcome to the SQN3330 firmware updater [1.2.3] >>> >>> GPy with firmware version 1.18.2.r3 The current delay is 1000 Response (+++ #1): None Response (AT #1) None Response (AT #3) None Response (AT #4) b'\r\n+SYSSTART\r\n' Response (AT #1 @ 115200) None Response (AT #2 @ 115200) None The current delay is 2000 Response (+++ #1): None Response (AT #1) b'\r\nERROR\r\n' Response (AT #2) b'\r\nOK\r\n' Response (AT+SMOD?) b'\r\n2\r\nOK\r\n' Converting response: 2 to int... Modem state: 2 Your modem is in application mode. Here is the current version: mirror? False recover? False resume? True direct? True atneg_only? False bootrom? False load_fff? False SYSTEM VERSION ============== FIRMWARE VERSION Bootloader0 : 5.1.1.0 [41065] Bootloader1 : 5.1.1.0 [39529] Bootloader2* : 5.1.1.0 [39529] NV Info : 1.1,0,0 Software : 5.1.1.0 [39529] by robot-soft at 2018-09-28 16:07:40 UE : 5.0.0.0d COMPONENTS ZSP0 : 1.0.99-13616 ZSP1 : 1.0.99-12355 IMEI: 354347099454842 >>>Here is the same info() for a working modem I have (updated a long time ago when 39529 came out. No idea what Pycom firmware I used)
<<< Welcome to the SQN3330 firmware updater [1.2.3] >>> >>> GPy with firmware version 1.18.2.r3 The current delay is 1000 Response (+++ #1): None Response (AT #1) b'\r\nERROR\r\n' Response (AT #2) b'\r\nOK\r\n' Response (AT+SMOD?) b'\r\n2\r\nOK\r\n' Converting response: 2 to int... Modem state: 2 Your modem is in application mode. Here is the current version: mirror? False recover? False resume? True direct? True atneg_only? False bootrom? False load_fff? False SYSTEM VERSION ============== FIRMWARE VERSION Bootloader0 : 5.1.1.0 [39529] Bootloader1* : 5.1.1.0 [39529] Bootloader2 : 5.1.1.0 [39529] NV Info : 1.1,0,0 Software : 5.1.1.0 [39529] by robot-soft at 2018-09-28 16:07:40 UE : 5.0.0.0d COMPONENTS ZSP0 : 1.0.99-13616 ZSP1 : 1.0.99-12355 IMEI: 354347092629911
-
Yea, I see that works as well. Thanks. Appears the latest 1.18.2 broke modem updates. Awesome...as if this deployment wasn't slow enough already :(
-
I was finally able to upgrade a couple of GPys based on a tip I read in another post. Downgrading the Pycom firmware to 1.18.1.r1 allowed the Sequans updater to successfully complete. I then flashed the GPy back to my current 1.20.0.rc8 firmware.
-
Exact same issues here as well. Just started to deploy a number of boards and so far we are 5 boards and 5 failures with the message "Waiting for updater to load...".
sqnsupgrade.run('/sd/deploy/lte_firmware/upgdiff_38638-to-39529.dup', debug=True)
How do we recover these modules now?!!! I have 75 more boards to do. What are we doing wrong????
-
@reidfo
Quite hopeless!
Today I have used a Fipy (instead of Gpy) and Expansion Board 3.0 (instead of 3.1 that I have used previously) and ended with same result.
Experiencing exactly the same scenario with brand new Fipy module with Expansion board 3.
This time all I have noticed as:
for the very first attempt of Cellular Firmware up-gradation outcome,>>> import sqnsupgrade >>> sqnsupgrade.run('/sd/CATM1-39529.dup', '/sd/updater.elf') <<< Welcome to the SQN3330 firmware updater [1.2.3] >>> >>> FiPy with firmware version 1.18.2.r2 Attempting AT wakeup... Session opened: version 1, max transfer 8192 bytes Sending 55570 bytes: [########################################] 100% Attempting AT auto-negotiation... ERROR sending AT command... no response? b'' AT auto-negotiation failed! Exiting. Unable to load updater from /sd/updater.elfIt dealt with, transfer 8192 bytes and sends 55570 bytes before crashing.
I can ensure that the updater.elf was in the SD card,>>> from machine import SD >>> sd = SD() >>> os.mount(sd,'/sd') >>> os.listdir('/sd') ['System Volume Information', 'CATM1-39529.dup', 'updater.elf', 'upgdiff_33080-to-39529.dup', 'upgdiff_38638-to-39529.dup', 'test.txt']Following on, every other attempts gives the result as,
>>> import sqnsupgrade >>> sqnsupgrade.run('/sd/CATM1-39529.dup', '/sd/updater.elf') <<< Welcome to the SQN3330 firmware updater [1.2.3] >>> >>> FiPy with firmware version 1.18.2.r2 Attempting AT auto-negotiation... Session opened: version 1, max transfer 2048 bytes Sending 429340 bytes: [########################################] 100% Waiting for updater to load...Waiting for updater to load... that I am dealing with!
Important here that, the transferring byte size is small, 2048 bytes always and sends 429340 bytes. with respect to the very first attempt of transfer 8192 bytes and sends 55570 bytes !So, what's going on?
What I am missing? Anything, new with the updater.elf that I am downloading is creating such a problem?
How can I erase and clean the Firmware for redoing again?
-
Here is the output I get when running the posted upgrade script that bypasses modem init.
Pycom MicroPython 1.20.0.rc8 [7b83c6d] on 2019-03-12; GPy with ESP32 Type "help()" for more information. >>> >>> run('/sd/CATM1-39529.dup', 921600) <<< Welcome to the SQN3330 firmware updater >>> Starting STP (DO NOT DISCONNECT POWER!!!) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 108, in run OSError: Invalid answer 'b''' from the device >>>
-
I am having the same problem with a new batch of GPys I ordered direct from Pycom. So far three of them have failed at various stages of a modem upgrade, and are not currently usable. I have tried multiple methods of updating (from SD, UART, UART with local copy of updater.elf, and the script posted a few months back for upgrading modems stuck in recovery mode). None have been successful. I'll start a new thread with those results, but I consistently get stuck at the "Waiting for updater to load..." message. I have tried the latest development and stable releases of the GPy firmware.
>>> import sqnsupgrade >>> sqnsupgrade.uart(True, '/flash/updater.elf') <<< Welcome to the SQN3330 firmware updater [1.2.3] >>> >>> GPy with firmware version 1.20.0.rc8 Your modem is in recovery mode. You will need to use firmware.dup and updater.elf file to upgrade. Preparing modem for upgrade... Attempting AT auto-negotiation... Session opened: version 1, max transfer 2048 bytes Sending 429340 bytes: [########################################] 100% Waiting for updater to load...```
-
Hi @rskoniec
May i ask for your kind attention in this problem. It seems very frustrating. Thanks in advance.Additional Note:
From a successful update example from a forum I can see the transfer file size is higher (8192 bytes) compared to my case (2048 bytes). Is that any issue. As you can see, my CATM1-39529.dup size is 5,918 KB and updater.elf is 420 KB!Starting STP (DO NOT DISCONNECT POWER!!!) STP started Session opened: version 1, max transfer 8192 bytes Sending 5665583 bytes: [########################################] 100% Code download done, returning to user mode Resetting (DO NOT DISCONNECT POWER!!!)..