LTE M1 cellular firmware updating to Gpy stucks, says, Waiting for updater to load...

[reidfo]

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.

[panda]

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 :(

[panda]

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

[panda]

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.

[BorbonJuggler]

@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.

[BorbonJuggler]

@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.

[panda]

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]

@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.

[reidfo]

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.

[fidaforever]

@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

[panda]

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.

[panda]

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.

[reidfo]

@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.

[panda]

@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.