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

[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.

[Einar Thorsrud]

Hi,

I am glad to hear you fixed the issue, but I would not trust it as a stable fix. Using a different clock source will, of course, affect timing slightly, and in this case apparently for the better (It seems like the LFRC clock is a bit slower than the LFXO clock in this case). But in this case, the fix is marginal and likely to be affected by the chip to chip differences in the LFRC performance.

The only workaround is to update the SoftDevice version to >= 7.0.1, since the issue is with a hard-coded constant within the SoftDevice.