sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

[hathach]

Hi,

I have run into an issue with nrf52840 on pca10056 v1.0.0 board. The softdevice is SD v6.1.0. It seems to be a hardfault which cause a reset when I tried to call sd_flash_write(), sd_flash_page_erase() is OK though. The address and buffer is 4 byte aligned, the number of word is 1024.

Following the parameter of the callback error that Softdevice invoked

• id = 1 (NRF_FAULT_ID_SD_ASSERT)
• pc= 0x00014A3A
• info = 0x00

if SD is not enable, there will be no problems at all. Strange things is the very same code run without issue on nrf52832 S132 v6.1.0.

I am appreciated if anyone could provide a hint why SD assert at that pc location.

Thanks in advance

[Einar Thorsrud]

Hi,

I see this on my side as well. The assert indicate that the SoftDevice spends too much time writing to flash. I am not sure why though, as the API documentation states that the maximum number of words is 1024 (number of words in one flash page). I will look more into it and hopefully have more info on Monday.

[hathach]

Just saw the 6.1.1 release, any chances that this is fixed. Thanks

[jake.yoon]

Hi, Einar.

I'm suffering from this issue too though my buffer size is 512(bytes).

1. Does "DRGN-12539" affect only "LARGE buffers"?

I'm suspecting that the time scheduled for "sd_flash_write(p_dst, p_src, size)" is calculated according to the "size" in its arguments. Isn't it?

If so, the real time spent can be larger than expected(calculated) irrespective of size(i.e. buffer is LARGE or not).

2. Please let me know the detailed mechanism which softdevice is using to estimate the required time.

3. If this issue is not reliable fixed even in 7.0.1 and will be fixed in next MAJOR version, would it be 8.x?

[Einar Thorsrud]

Hi,

1. This is not the exact same issue as DRGN-12539. The fix there in 7.0.1 is for erase operations only, not for write operations.

2. This is a fixed number that is calculated beforehand and hardcoded in the SoftDevice, and the timeout is supposed to be set to after the maximum write duration. But the bug discussed in this thread is because this timeout is set too low.

3. It is not fixed in 7.0.1. It will most likely be fixed in the next major SoftDevice release, but I cannot promise anything.

[jake.yoon]

Thank you for the prompt reply, Einar.

Please confirm if my understanding is right.

1. SD before 7.0.1 (such as SD 6.1.1) may raise "NRF_FAULT_ID_SD_ASSERT" on "sd_flash_page_erase()"

2. "sd_flash_write()" is safe on all SD versions(e.g. 6.1.1, 7.0.1) as long as the buffer size is less than 1024 words.

[Einar Thorsrud]

1. Yes.

2. No. sd_flash_write() with large words are not safe. The safe buffer length depends on the location of the source buffer (flash or RAM). Based on the tests we have done, 512 words are always safe. In practice, the limit seems to be about ~800 words if the source buffer is in RAM, but I cannot guarantee an exact number.

[jake.yoon]

Ok, I got it.

Then, my issue must come from "sd_flash_page_erase()" because my buffer size is only 128 words (512 bytes).

In my case, to change LF clock source to LFRC from LFXO alleviates the problem but I don't know how it affects. Of cource, LF clock has relation with the scheduler of softdevice.

but I don't like to change the clock source to LFRC.

Do you know any other workaround for the problem?

[Einar Thorsrud]

Is updating to 7.0.1 an option? If so, then that would be the natural way to fix this issue (assuming this really is the issue you are seeing).

[jake.yoon]

That would be an option but 7.0.1 is supported only by SDK 16,0,0 not by 15.3.0 which I'm using.

In fact, I am not comfortable with x.0.0 versions.

SDK 16.1.0 may come to us soon, isn't it?

It's been half an year since 16.0.0 is released. :-)

[Einar Thorsrud]

Hi,

I don't think you should see the x.0.0 as an indication of a lack of quality in the nRF5 SDK context. It has stabilized over the years, and the recent/current policy is to increase the SDK major version number when it is designed to be used with a different SoftDevice major version. So you can assume that the next nRF5 SDK version will be 17.0.0, though I cannot say that for sure. I recommend you contact sales if you need details about the schedule.

[jake.yoon]

OK, I see.

Thank you for the advice.

Have a nice weekend.

[jake.yoon]

By the way, in my case, to change LF clock source to LFRC from LFXO seems to resolve the problem.

Please let me know the mechanism behind the issue to find another way for the problem.