GPY loss of attachment ability

[kjm]

I've managed to get 2 GPY lte modems into a state where they can no longer attach, presumably because of an AT cmd sequence

lte.send_at_cmd('AT+CEREG=2;+CEREG?;+CEREG=0') 

I was evaluating. Since I'm now down to only one working GPY I've been trying to get them working again. So far I've tried;
ATZ
AT^RESET
AT+SQNSFACTORYRESET followed by AT^RESET
and reflashing the modems firmware
to no avail. Can anybody suggest something I haven't thought of? I guess I'm after something to erase the modem flash where it keeps the persistent results of changes wrought by AT cmds
Is there anybody with a surplus of GPYs willing to risk

lte.send_at_cmd('AT+CEREG?') 

so I can see what the default modem should be?

[Gijs]

Hi,
Over the last year we have changed a big part of our LTE stack, including changing the CEREG setting (in version 1.20.2.r2). Check whether the CEREG setting is set to 1, or change it to 1 using the following:

from network import LTE
lte = LTE()
print(lte.send_at_cmd('AT+CEREG=1'))

[Eric Arnoldy]

I know this is a year later, but I'm in a similar boat .. my Pycom is now reporting same thing. I'm running FiPy though, 1.20.2.r4 ... everything was running just fine and I brought it in to flash from r1 to r4 then this happened. Its actually happened to 3x of mine now. So something isn't happy.

PYCOM
FiPy
UE5.0.0.0d

OK

[kjm]

I maybe got a clue to what's going on https://forum.pycom.io/topic/4915/gpy-pytrack-modem-won-t-attach-after-firmware-upgrade/7 with responses to print(lte.send_at_cmd("ATI"))
My one working GPY responds SEQUANS Communications VZM20Q UE5.0.0.0d whereas the dead ones reply PYCOM FiPy UE5.0.0.0d God knows how a cereg cmd makes the lte modem think its FiPy?!