• State Suggested Answer
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 74 subscribers
  • Views 3338 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 254769
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

OTA-DFU sometimes erases the application data unexpectedly

keni3

Hi,

We are facing an issue where the application data stored using FDS is erased one in a while after OTA-DFU multiple times.

This issue does not occur all the time, but it appears as often as 5% of the times.

We are developing the customized application based on the ble_peripheral/ble_app_uart example with the following environment:

  • Target Chip: nRF52832
  • SDK: v16.0.0
  • Soft Device: s132
  • Compiler: IAR

For the DFU, I used secure_bootloader exmaple and combined these 2 application to crated 1 .zip file by nrfutil to upload via nRF Tools app (either iOS or Android).

I have made sure that the following parameters are matched:

// In nrf_dfu_types.h
DFU_APP_DATA_RESERVED CODE_PAGE_SIZE * 3

// In sdk_config.h
FDS_VIRTUAL_PAGES 3

This problem occurs regardless of the application size to be uploaded, i.e. it doesn't matter if it's single-bank or dual-bank update.

Is there any possible factor this issue to happen only sometimes?

If anyone can suggest the way to resolve or to reproduce the issue with 100% frequency, it would be so helpful!

Thank you.

Parents
  • 0

    Update from my investigation on this issue.

    I have checked the error returned from fds_record_find() at the initialization process and found out that it was returning FDS_ERR_NOT_FOUND error.

    Also I found out that there was a bug in my initialization process where FDS delete and write accesses are made every time my application is initialized.

    After removing this bug, the issue doesn't seem to occur any more as long as I tried so far.

    Do you think this was the cause? If so, what could be causing the FDS_ERR_NOT_FOUND error and why was it happening only once in a few times?

    Since I'm not yet 100% sure if the problem is really resolved, I would like to know what was going on in detail to nail down the real cause.

Reply
  • 0

    Update from my investigation on this issue.

    I have checked the error returned from fds_record_find() at the initialization process and found out that it was returning FDS_ERR_NOT_FOUND error.

    Also I found out that there was a bug in my initialization process where FDS delete and write accesses are made every time my application is initialized.

    After removing this bug, the issue doesn't seem to occur any more as long as I tried so far.

    Do you think this was the cause? If so, what could be causing the FDS_ERR_NOT_FOUND error and why was it happening only once in a few times?

    Since I'm not yet 100% sure if the problem is really resolved, I would like to know what was going on in detail to nail down the real cause.

Children
  • 0 in reply to keni3

    Hi,

    Without knowing the details of the bug that you fixed, I cannot tell if it could be the cause or not. It is not unreasonable that fds_record_find() returns FDS_ERR_NOT_FOUND if the record that you search for gets deleted and rewritten close in time to that. Permanent loss of records _might_ be explained by erasing/rewriting records, if for instance resets occurs so that records are deleted, then reset happens before the record is written again.

    There has been some other reports of strange behavior after DFU after initial programming was done with the nRF Connect Programmer app. It does seem to be related to resets. From what I understand, when programming one or multiple hex files using the nRF Connect Programmer app, there may be one or more resets of the device as part of that process, which means the device may run briefly in the middle of being programmed. If that turns out to be the case, then that could be related to what you have been experiencing, in combination with erasing/writing records on startup.

    We are currently looking into the Programmer app issue. For now I recommend using nrfjprog, part of nRF Command Line Tools, for programming the device, and especially so if using DFU.

    Regards,
    Terje

Related
Terms of service