RC7620 registration problem

[jyijyi]

Not sure when these message happens …

Do you see this after FW upgrade for this module?

[befaoim]

Hi,

No sure to fully understand your question.
For the second module, the product was shipped and the module failed after.
That module was updated, tested, assembled in our product and retested. So we are sure it worked well.

Do you think that a power supply problem can cause this issue? What’s happen if the module main power supply is suddenly turned off when it is working (or in shutdown phase) ?

[jyijyi]

I mean i don’t know if these messages appear in the field or not:

00:00:00.000,H0082402,CRASH=MPSS,FILE=fs_device.c,LINE=401,STR=[-2095636730] Unexpected device read failure,TASK=AMSS,VER=SWI9X07H_00.08.24.02
00000,1980/01/06 00:00:00.000,H0082402,CRASH=Unknown,FILE=,LINE=0,STR=,TASK=,VER=

BTW, do you follow the power off sequence in PTS?

[befaoim]

Ok.
Yes, we follow the power off sequence but our product power supply ( batteries) can be disconnected by the user at any time. We cannot predict when this will occur.

[jyijyi]

i check again “RC7620_Bricked_module.txt”, I think the upgrade process is not yet completed…

00000,1980/01/06 00:00:00.000,H0082402,CRASH=MPSS,FILE=fs_device.c,LINE=401,STR=[-2095636730] Unexpected device read failure,TASK=AMSS,VER=SWI9X07H_00.08.24.02
00000,1980/01/06 00:00:00.000,H0082402,CRASH=Unknown,FILE=,LINE=0,STR=,TASK=,VER=
00000,1980/01/06 00:00:18.298,H0082402,BACKUP_SYNC,PART_TO_FILE=NVBK_FULL_Factory.001,STATUS=PASS
00000,1980/01/06 00:00:20.349,H0082402,BACKUP_SYNC,PART_TO_FILE=NVBK_FULL_Provision.002,STATUS=PASS
00000,1980/01/06 00:00:20.498,H0082402,NV_REBUILD=START,COMMENT=FW ver: SWI9X07H_00.08.24.02 f90cbd jenkins 2022/03/21 03:47:54,FILE=/swibackup/NVBK_FULL_Provision.002
00000,1980/01/06 00:00:30.862,H0082402,NV_REBUILD=COMPLETE,COMMENT=defaulted 0, restored 1495, skipped 0, failed 0,STATUS=PASS
00000,1980/01/06 00:00:33.253,H0082402,NV restore NV_SWI_EF_LOG_I index=0 from Cache
00005,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00005,1980/01/06 00:00:00.000,
00006,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00006,1980/01/06 00:00:00.000,
00006,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00006,1980/01/06 00:00:00.000,
00007,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00007,1980/01/06 00:00:00.000,
00007,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00007,1980/01/06 00:00:00.000,
00007,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00007,1980/01/06 00:00:00.000,
00007,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00007,1980/01/06 00:00:00.000,
00007,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00007,1980/01/06 00:00:00.000,
00007,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00007,1980/01/06 00:00:00.000,
00007,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00007,1980/01/06 00:00:00.000,
00008,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00008,1980/01/06 00:00:00.000,
00008,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00008,1980/01/06 00:00:00.000,
00008,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00008,1980/01/06 00:00:00.000,
00008,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00008,1980/01/06 00:00:00.000,
00008,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00008,1980/01/06 00:00:00.000,
00009,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00009,1980/01/06 00:00:00.000,
00009,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00009,1980/01/06 00:00:00.000,
00009,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00009,1980/01/06 00:00:00.000,
00009,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00009,1980/01/06 00:00:00.000,
00009,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00009,1980/01/06 00:00:00.000,
00009,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00009,1980/01/06 00:00:00.000,
00009,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00009,1980/01/06 00:00:00.000,
00009,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00009,1980/01/06 00:00:00.000,
00009,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00009,1980/01/06 00:00:00.000,
00009,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00009,1980/01/06 00:00:00.000,
00009,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00009,1980/01/06 00:00:00.000,
00010,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00010,1980/01/06 00:00:00.000,
00010,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00010,1980/01/06 00:00:00.000,
00010,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00010,1980/01/06 00:00:00.000,
00010,1980/01/06 00:00:00.000,H0082402,no meta data:didn't write
00010,1980/01/06 00:00:00.000,

[befaoim]

Ok. But this cannot explain our module behavior.

Is there a generated log file when we update a module?

[jyijyi]

you can take the RC7620_working_module.txt as reference as you say it is OK module

[befaoim]

I don’t speak about the log file generated by the module itself.

Is there a log file generated by the update exe ?

[jyijyi]

you can see here:

Fdt2.exe - is there a way to capture its stdout?

For some batch/automated FW update I would like to capture fdt2.exe’s “console” output into the file. If I use Windows shell redirection for STDOUT and STDERR they both yield empty files. It seems fdt2.exe opens some sort of ‘external’ console window where the actual output is written. Is there any elegant way to capture/save it? Alternatively I could analyse log files created using -log option but they seem to be pretty massive (~400kB per successful run of fdt2). Thanks.

[nigel.heard]

We are having the same problem here, RC7620 modules updated and working correctly during both production test and pre-deployment testing but randomly failing in the field. The following is output from our testing:

ATIManufacturer: Sierra Wireless, Incorporated
Model: RC7620-1
Revision: SWI9X07H_00.08.44.07 2539f0 jenkins 2023/04/26 10:17:51
IMEI: 351080657501851
IMEI SV: 28
FSN: 7T2422300616B1
+GCAP: +CGSM

OK
AT!PCINFO?;!IMAGE?;!IMPREF?State: Low Power Mode
LPM voters - Temp:0, Volt:0, User:0, W_DISABLE:0, IMSWITCH:1, BIOS:0, LWM2M:0, OMADM:0, FOTA:0, RFCAL:0, AVMS:0
LPM persistence - None

TYPE SLOT STATUS LRU FAILURES UNIQUE_ID BUILD_ID
FW 1 EMPTY 0 0 0
FW 2 EMPTY 0 0 0
FW 3 EMPTY 0 0 0
Max FW images: 1
Active FW image is at slot 255

TYPE SLOT STATUS LRU FAILURES UNIQUE_ID BUILD_ID
PRI FF GOOD 0 0 0 001.081_000 00.08.07.00_GENERIC
PRI FF GOOD 0 0 0 000.058_000 00.08.07.00_SIERRA
Max PRI images: 50

!IMPREF:
preferred fw version: 00.08.07.00
preferred carrier name: GENERIC
preferred config name: GENERIC_001.081_000
preferred subpri index: 000
current fw version: 00.08.44.07
current carrier name: GENERIC
current config name: GENERIC_001.081_000
current subpri index: 000

fw version mismatch

OK
AT!ENTERCND="A710"OK
AT!FLOG?!FLOG:

OK
Class long:

00201,1980/01/06 00:00:08.225,H0084407,COMMENT=Log created,LOG_VERSION=1.0

00201,1980/01/06 00:00:00.000,H0084407,no meta data:didn’t write

00201,1980/01/06 00:00:00.000,

00202,1980/01/06 00:00:00.000,H0084407,no meta data:didn’t write

00202,1980/01/06 00:00:00.000,

00203,1980/01/06 00:00:00.000,H0084407,no meta data:didn’t write

00203,1980/01/06 00:00:00.000,

00204,1980/01/06 00:00:00.000,H0084407,no meta data:didn’t write

00204,1980/01/06 00:00:00.000,

00205,1980/01/06 00:00:00.000,H0084407,no meta data:didn’t write

00205,1980/01/06 00:00:00.000,

00206,1980/01/06 00:00:00.000,H0084407,no meta data:didn’t write

00206,1980/01/06 00:00:00.000,

00207,1980/01/06 00:00:00.000,H0084407,no meta data:didn’t write

00207,1980/01/06 00:00:00.000,

00208,1980/01/06 00:00:00.000,H0084407,no meta data:didn’t write

00208,1980/01/06 00:00:00.000,

00209,1980/01/06 00:00:00.000,H0084407,no meta data:didn’t write

00209,1980/01/06 00:00:00.000,

00210,1980/01/06 00:00:00.000,H0084407,no meta data:didn’t write

Please advise, this has become a critical issue for our production.

[jyijyi]

are you sure module in the field can follow the power off sequence mentioned in the PTS?

It seems the required FW has been deleted or corrupted