Updating FDS file during BLE communication may corrupt the file.

[Kirinyaga]

In the following cases, we have confirmed corruption of FDS files with a low probability.

1)Updated FDS file during BLE communication.

2)Updated FDS file after BLE communication was disconnected.

Corrupted files appear to be written with data that appears to have been copied from deleted areas of the FDS.

Attached is a part of the FDS dump when the phenomenon occurred.

---

:104C200055000000000001001500C1B0390100006E

C)
:104C300005018000000004001C0033C03A010000A0
:104C400098E8CE1DD5AFC818580FDB803C36000061
:104C50000000140001C063163B010000014B8B4CA7
:104C60005A70DA8DA39A03515539C3E06700F47284
:104C70004E47095C0000000000000000000000003A

---

A)

:104E5000D5AFC818580FDB807034000000000F0079
:104E600016008CCF4601000000000200FFFF00008A
:104E7000FFFF0000FFFF000061726B7261796D65DA
:104E80007465722E7765622E6170702F74312F0AEF
:104E90000000000000000000000000000000000012
:104EA00055000000000004001C00070B4701000033
:104EB00098E8CE1DD5AFC818580FDB8032370000F8
:104EC00000000F001600AAE948010000FFFFFFFFE5
:104ED000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE2
:104EE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD2
:104EF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC2

B
:104F0000FFFFFFFFFFFFFFFF00000F001600C76558
:104F10004901000005018000F80402001C0033C0B4
:104F20003A01000098E8CE1DD5AFC818580FDB80B5
:104F30003C3600000000140001C063163B01000075
:104F4000014B8B4C5A70DA8DA39A03515539C3E04B
:104F5000000004001C00A3414A01000098E8CE1D97

---

A)

Original data. (File ID: 0x0016)

B)

Corrupted data.

The expected value is data that differs from A) by only a few bytes.

C)

Corrupted data was overwritten with the contents of this area.

This area contains multiple files, including file headers.

Also, it is not the area of File ID: 0x0016.

inquiry:

• What controls can cause this phenomenon?
• How can I modify the user code to avoid this phenomenon?

[Sigurd]

Hi,

What SDK version are you using ?

[Kirinyaga]

Thank you for answering.

I'm using nRF5_SDK_17.1.0_ddde560.

[Sigurd]

Hi,

Kirinyaga said:

I'm using nRF5_SDK_17.1.0_ddde560.

Good.

What controls can cause this phenomenon?

In case of power-loss, data could be written incompletely. But FDS recognizes invalid data and never returns corrupted data to the user.

[Kirinyaga]

Sigurd said:

But FDS recognizes invalid data and never returns corrupted data to the user.

I understand your explanation.

However, unlike the description, corrupted data is returned to the user application.

Sigurd said:

In case of power-loss, data could be written incompletely.

For example, if the voltage drops momentarily (or some other reason),  could the FDS mistakenly think the data was written correctly even though the data was written incompletely?

[Sigurd]

Hi,

Could you check if you have power-fail comparator(POF) enabled in your application? If power-fail warning is enabled and the supply voltage is below V_POF the power-fail comparator will prevent the NVMC from performing write operations to the NVM.

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/power.html?cp=5_2_0_17_3_0#unique_1204650543

[Kirinyaga]

Sigurd said:

Could you check if you have power-fail comparator(POF) enabled in your application?

In my application I just enabled POF when writing FDS.

Sigurd said:

If power-fail warning is enabled and the supply voltage is below V_POF the power-fail comparator will prevent the NVMC from performing write operations to the NVM.

Thank you for the information about the POF specification.

I will try disabling POF in my application.