WP8548 fw mismatch after flash

IoT Modules WP Series
1

Hello,

We would like to understand why our production team flashing latest SKU of WP8548 have problem with “fw mismatch” causing low power mode (confirmed by AT!PCOFFEN?) and thus stopping radio when flashing with fdt2 (Windows tool) our custome .spk image. This problem occurs randomly but not rarely and we could only solve it by reflashing a second time. Is there a way to change preferred fw version ? :

After flashing custom image (with GENERIC modem version 07.13.07.00) :

root@swi-mdm9x15:~# cm info
Device: WP8548
IMEI: 359377062405906
IMEISV: 2F
FSN: LL210400811610
Firmware Version: SWI9X15Y_07.13.07.00 92cfd2c jenkins 2018/08/22 19:18:52
Bootloader Version: SWI9X15Y_07.13.07.00 92cfd2c jenkins 2018/08/22 19:18:39
MCU Version: 002.004
PRI Part Number (PN): 9907131
PRI Revision: 01.02
Carrier PRI Name: GENERIC
Carrier PRI Revision: 001.032_000
SKU: 1103453
Last Reset Cause: Unknown
Resets Count: Expected: 0 Unexpected: 0

AT!IMPREF:
preferred fw version: 07.11.22.00
preferred carrier name: GENERIC
preferred config name: GENERIC_001.032_000
current fw version: 07.13.07.00
current carrier name: GENERIC
current config name: GENERIC_001.032_000

fw version mismatch

root@swi-mdm9x15:~# cm radio
Power: OFF
…

After flashing custom image 2nd time :

root@swi-mdm9x15:~# cm info
Device: WP8548
IMEI: 359377062405906
IMEISV: 2F
FSN: LL210400811610
Firmware Version: SWI9X15Y_07.13.07.00 92cfd2c jenkins 2018/08/22 19:18:52
Bootloader Version: SWI9X15Y_07.13.07.00 92cfd2c jenkins 2018/08/22 19:18:39
MCU Version: 002.004
PRI Part Number (PN): 9907131
PRI Revision: 01.02
Carrier PRI Name: GENERIC
Carrier PRI Revision: 001.040_000
SKU: 1103453
Last Reset Cause: Unknown
Resets Count: Expected: 0 Unexpected: 0

AT!IMPREF:
preferred fw version: 07.13.07.00
preferred carrier name: GENERIC
preferred config name: GENERIC_001.040_000
current fw version: 07.13.07.00
current carrier name: GENERIC
current config name: GENERIC_001.040_000

root@swi-mdm9x15:~# cm radio
Power: ON
Current Network Operator: F SFR
Current RAT: UMTS network (LE_MRC_RAT_UMTS)
Status: Not registered but currently searching for a new operator (LE_MRC_REG_SEARCHING)
Signal: Very weak signal strength (1)
PS: Packet Switched Not registered (LE_MRC_REG_NONE)

We tried these to solve it without re-flashing, using both these commands but without success :

AT!IMPREF=“GENERIC” > ERROR
AT!RESET

or
AT!IMPREF=“AUTO-SIM” > OK
AT!RESET

Best Regards,
Marc

2

Did you compare the log of fdt2.exe?
How about using local upgrade command “fwupdate download xxx.spk” ?

3

Thanks for your help but in both cases log precise firmware downloaded successfully.

In production sequence to flash modules before hardware test, in order to speed up things we set hardware pin TP1 to ground in order to force to boot mode and flash firmware.
“fwupdate” option would need to let the module start, then ssh, then upload .spk and then apply it.

4

Can you post your fdt2 log here?

It might be the stability problem of your PC.
you can change another Windows PC and see if there is improvement.
Also you can use some linux machine with swiflash to download the spk and see if there is any improvement.
You can also put TP1 to normal and upgrade with fdt2 and see if there is any improvememt

5

Hello jyijyi,

Here are fdt2 programming logs when firmware flashed OK

FDT version: 2.0.2012.0

Awaiting suitable port or adapter …

Switching to streaming mode …

Downloading images …

Writing image /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|

Flashing image /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/

Enabling selective suspend …

Firmware image download succeeded.

Final Firmware update succeeded.

Preexisting images information:

Current:

  Firmware:


  	ImageId: 


  	BuildId: 


  Configuration:


  	ImageId: 


  	BuildId:

Final images information:

Current:

  Firmware:


  	ImageId: 


  	BuildId: 


  Configuration:


  	ImageId: 


  	BuildId:

OEM PRI:

IMEI:

Total time elapsed: 36250 ms.

Images downloaded:

Image ID: 001.040_000

Build ID: 07.13.07.00_GENERIC

  write time: 5781 ms


  additional flash time: 20500 ms

Time to reset to application mode: -1 ms.

and when the problem occurs :

FDT version: 2.0.2012.0

Awaiting suitable port or adapter …

Switching to streaming mode …

Downloading images …

Writing image /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|

Flashing image /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-

Enabling selective suspend …

Firmware image download succeeded.

Final Firmware update succeeded.

Preexisting images information:

Current:

  Firmware:


  	ImageId: 


  	BuildId: 


  Configuration:


  	ImageId: 


  	BuildId:

Final images information:

Current:

  Firmware:


  	ImageId: 


  	BuildId: 


  Configuration:


  	ImageId: 


  	BuildId:

OEM PRI:

IMEI:

Total time elapsed: 36578 ms.

Images downloaded:

Image ID: 001.040_000

Build ID: 07.13.07.00_GENERIC

  write time: 5782 ms


  additional flash time: 20812 ms

Time to reset to application mode: -1 ms.

We can’t see differences here…

Thanks for your suggestions though It would be complex to switch to linux machine on production bench.

BR,
Marc

6

You can also put TP1 to normal and upgrade with fdt2 and see if the log will show differently in the NOK case

7

We will try it indeed but we have to modify our process then.
We are also trying with another more confortable (RAM memory size) windows PC.