FiPy LTE modem update failed

[Hadrien Libioulle]

Hi everyone,

For a master thesis, I am using a FiPy with a PyTrack to create a LoRa/LTE tracker device.

While testing the device, I needed to switch between LTE-M and NB-IoT and to do that on the FiPy, we have to flash the firmware of the modem via SQN3330 firmware updater tool (sqnsupgrade package) but I had to shut down the board because the updater was stuck/unresponsive (blocked for more than 10 minutes on a “Do not shutdown” message even though the update was not that slow previously).

Now, the modem is completely unresponsive and I cannot flash it anymore (I receive messages like "Could not detect your modem!" and "Please try to power off your device and restart in safeboot mode." however, rebooting the board does not solve the issue).

When I try to manually connect to the serial interface of the modem (which I can also see if I upgrade/get the info of the modem in debug mode), the modem outputs only "\x00\x00\x00...." and so on, which I assumed means the modem is not powered on.

Could anyone help me on this ?

Thanks in advance 😉.

[Hadrien Libioulle]

@Elizar Thanks for your answer 😁 Hopefully, I have not bricked the modem but I think you are right and I have unfortunately bricked it ... I have contacted Pycom support to know if they have a way to repair it. If not, then I will probably just buy a new one. Thanks again 😉.

[Elizar]

I have flashed some dozens of devices with the NB-IoT modem software and delays of about 10 minutes are not unusual. Bad news: you may have bricked your device by interrupting the process too early.

As a wild guess I suspect the flash process has three stages. First, the update image is copied from FiPy to the internal SQN-RAM. This already takes some time, but we can observe some progress in the updater tool.
Secondly, the new image is actually written to the internal FLASH. This takes a remarkable long time; maybe some verify-after-write testing is involved with an incredible slow FLASH or the SQN-internal update program runs on a very, very slow CPU. During the second stage, nothing can be observed from the outside. Therefore the updater appears to be stuck. This is a dangerous moment for disconnecting the power supply since the new FLASH image is still incomplete.
Thirdly, when the FLASH write is completed, the SQN chip reboots. As far as I can guess from the available docs, the SQN chip features an internal (mini Linux like) operating system that has to reboot. The reboot time can be measured by sending a reset command sequence to the SQN chip and then taking the time until the SQN becomes responsive again.

You may try to flash the modem again with more patience and sometimes this may be successful if you are lucky. If not, your modem may be bricked. Then you would need at least some more advanced hardware like a JTAG programmer for the modem and a complete chip documentation. But it may be by far more time & cost efficient to just replace the FiPy.

Just for curiosity: does anyone here have more detailed docs about or some insight into the internal steps of the update process?