• State Not Answered
  • Replies 5 replies
  • Subscribers 71 subscribers
  • Views 888 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 303932
Options

nRF5340 - program lost

Gabriele

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

  • 0

    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

  • 0 in reply to tesc

    Hi Terje,
    unfortunately our service guys have already reprogrammed the units.
    I've asked them to let me to investigate next time.


    Best Regards.

  • 0 in reply to Gabriele

    Hi,

    I understand. Yes, getting access to a device which is in the faulty state, preferably full flash contents, would be valuable in assessing what might have happened. Also if there is any logs kept, or any other information about what has been happening prior to the device failing.

    Regards,
    Terje

  • 0

    We are in the midst of developing a product on nRF5340 and had a similar customer report this week.

    From my customer, it sounds like it occurred when they let the LiPo battery drain. Once it reaches about 3.0V, the LiPo battery PCM circuit would effectively do a hard shutdown of the device, including the nRF5340

    We are working to repeat and/or extract the flash file contents to understand better.

    As mentioned, we are in the midst of developing the product, so glad we observed it at this stage.

    It is surprising. In the customer's state, the nRF5340 was running some algorithms, but none of our application would be doing flash write operations at that time. So a flash corruption may not be expected.

    I'll dig further into Nordic documentation about shutdown scenarios as such.

    We do monitor our battery level, so we could "hibernate" appropriately, if that would help in this scenario.

  • 0 in reply to tesc


    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

Related