nRF5340 - program lost

Hi,
A couple of customers have returned the product back after a month of regular use.
The nRF5340 had lost the internal program.
Has anybody else experienced the same with the nRF5340 ?
Is there any means to diminish the chance of such occurrence ?

Some device's info:
Chip variant 0x41414141
Chip config 0x112
Chip id: 0x6687373ca7d1fa21

Parents
  • Hi,

    The nRF5340 had lost the internal program.

    If we are talking about full flash erase, NVMC protection mechanisms may be a solution to the issue.

    Other than that, I am afraid we need more info for suggesting what might be the issue and how it might be mitigated. What is the nature of the loss of program, is it a (small) flash corruption, full flash erase, bootloader failing to confirm application, or other? Are you able to take a flash dump from the device? If so then feel free to share it in a private ticket, for confidentiality, and refer back to this case. Use e.g. nrfjprog --readuicr --readcode dump.hex for dumping flash contents to a hex file.

    Regards,
    Terje


  • Hi,

    The problem showed up again at customer in the field.
    This time I had the chance to dump the memory content of the faulty unit, before and after flash reprogramming, using $ nrfjprog --readuicr --readcode dump.hex

    The attached files are

    dump_corrupted.hex: the memory content before reprogramming
    dump_good.hex: the memory content after reprogramming

    The first difference occurs at offset 578CC.
    Are corrupted data content random information or valid opcodes ?
    Can anybody suggest the possible root cause of the memory corruption ?
    Maybe improper power supply or ESD event ? Maybe unsafe write operation little-fs from application ?

    3443.flash_dump_content.zip

Reply

  • Hi,

    The problem showed up again at customer in the field.
    This time I had the chance to dump the memory content of the faulty unit, before and after flash reprogramming, using $ nrfjprog --readuicr --readcode dump.hex

    The attached files are

    dump_corrupted.hex: the memory content before reprogramming
    dump_good.hex: the memory content after reprogramming

    The first difference occurs at offset 578CC.
    Are corrupted data content random information or valid opcodes ?
    Can anybody suggest the possible root cause of the memory corruption ?
    Maybe improper power supply or ESD event ? Maybe unsafe write operation little-fs from application ?

    3443.flash_dump_content.zip

Children
No Data
Related