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:

    1. Basically, I followed the guideline video by Chris as here, Pycom GPy & FiPy Cellular LTE Firmware Update, Core Electronics.

    2. So, I updated 3 firmware, as below:
      i. Firmware for the Expansion Board, following Expansion 3.1 Firmware Update. Outcome as,
      a) Device:
      0_1552357639299_Device Manager.png
      b) Firmware confirmation

       C:\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: 0_1552357783638_Pycom Upgrade-4.png

    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 subscriptable

    Thus 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.elf
    

    Extra look:

    1. My SD card snap:
      0_1552358165741_Disk-3.png
    2. 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.elf
    

    It 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 @BorbonJuggler

    For 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.elf
    

    It 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!!!)..
    


Pycom on Twitter