GC02S burn failed with CRC error

LTE Cat 1 / Cat 1 bis (Calliope)
1

There is a random upgrading error:

Error outputs :caba (error): crc computed = 0xb666c83f, crc expected = 0xbff7c705.

Confirmed Information:

  1. The file was buring into flash is exactly the app.dup file with right size and right CRC32 value “0xbff7c705” at the tail of the file

  2. call “at+sqnsupgrade=“file:///upgrade/custom.bin”,0,1,1” command to excute upgrade.

  3. Probability of occurrence: 1/30~1/15

  4. The whole upgrading process: Donwload source package(has our company privated header data) into /upgrade from an URL and checksum check→Extract app.dup from source package, named /upgrade/custom.bin→Call at+sqnsupgrade to upgrade

  5. Attached file(crc-error.log) is our PXL log file. check it at line #6546 please.

crc-error.log (556.3 KB)

2

The Sequans framework already provides a complete and validated FOTA mechanism through the AT+SQNSUPGRADE command, which directly points to the server hosting the upgrade image. This framework manages both the download and the application of the new firmware image.

It is therefore not necessary to:

  • Download the image separately
  • Extract the source package
  • Rename the file
  • Check CRC
  • Reinvoke AT+SQNSUPGRADE manually

Rebuilding or manipulating the file fragments multiple times introduces unnecessary risk. Given the target processor’s limited memory and processing capability, additional handling can increase vulnerability to:

  • Memory overlap issues
  • Memory constraints during download or decompression
  • Buffer corruption
  • Incomplete flash writes

About the Specific Issue, I can only speculate

Since the upgrade succeeds 29 times out of 30:

  • The file format is correct.
  • The CRC logic is correct.

If either were incorrect, the failure would occur 100% of the time.

An intermittent CRC or signature verification failure strongly indicates:

The data being hashed during the failing iteration is not identical to the original image.

This suggests possible data corruption during write or read operations, or memory instability.

Potential causes include:

  • Write operation crossing flash boundaries
  • Flash erase/write timing issues
  • Cache not flushed before verification
  • Partial sector programming

Recommended Debug Steps

To isolate the issue:

  1. Dump /upgrade/custom.bin after a successful upgrade.

  2. Dump /upgrade/custom.bin after a failed upgrade.

  3. Compare byte-by-byte:

    • Success case vs. failure case
    • Original image vs. failure case
    • Original image vs. success case

It is likely that 1–2 corrupted bytes will be identified in the failure case.

Other tips:

Concurrency Considerations

Please verify that the upgrade process is not running concurrently with:

  • Another task writing to flash
  • File system operations
  • Background logging
  • Any task accessing the same flash region

The logs show multiple mp_fopen calls on the same file in rapid succession. If the file system driver or flash controller experiences latency, update.exf may be closed, renamed, or accessed before final buffers are fully flushed from RAM to flash.

Recommendation

To avoid instability during deployment, it is strongly recommended to use the existing and validated AT+SQNSUPGRADE mechanism end-to-end for downloading and flashing the image, rather than manually reconstructing or handling file fragments before invoking the upgrade command.

This minimizes exposure to memory constraints, file handling risks, and flash integrity issues on a resource-limited target system