sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Einar Thorsrud — Mon, 20 Apr 2020 12:41:24 GMT

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.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Jake Yun — Mon, 20 Apr 2020 04:42:10 GMT

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.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Jake Yun — Sat, 18 Apr 2020 01:46:03 GMT

OK, I see.

Thank you for the advice.

Have a nice weekend.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Einar Thorsrud — Fri, 17 Apr 2020 15:16:20 GMT

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.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Jake Yun — Fri, 17 Apr 2020 15:00:01 GMT

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. :-)

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Einar Thorsrud — Fri, 17 Apr 2020 14:23:39 GMT

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

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Jake Yun — Thu, 16 Apr 2020 10:33:48 GMT

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?

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Einar Thorsrud — Thu, 16 Apr 2020 10:03:20 GMT

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.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Jake Yun — Thu, 16 Apr 2020 00:36:34 GMT

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.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Einar Thorsrud — Wed, 15 Apr 2020 14:54:13 GMT

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.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Jake Yun — Wed, 15 Apr 2020 02:41:05 GMT

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?

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Einar Thorsrud — Fri, 10 Jan 2020 12:37:30 GMT

Hi,

The statements you refer to relate to updates that have also impacted the issue with writing large buffers to nRF52840, but you should not assume that the issue is reliably fixed. The next major version of S140 will incorporate a proper fix.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Dan Halbert — Thu, 09 Jan 2020 15:23:19 GMT

Hi, following up, has this been fixed in 7.0.x? In the 7.0.0 Release Notes, I see:

The time scheduled for a flash write or flash page erase using sd_flash_write or sd_flash_page_erase APIs on nRF52811 will be longer than required and the same as for nRF52832.

And in 7.0.1, I see:

Fixed an issue where the time scheduled for a flash write or flash page erase using sd_flash_write or sd_flash_page_erase APIs on nRF52811 will be longer than required and the same as for nRF52832 (DRGN-12539)

Perhaps is this implying the scheduled time was lengthened in 7.0.0 to allow a full page write (and made more precise in 7.0.1), but that would be a guess.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Nandi — Thu, 18 Apr 2019 06:00:34 GMT

thank you for your reply, According to the way you said, it can be solved. I have another problem here. I use the internal Flash to make a U disk. I can't call the flash write function in the usb interrupt and it will timeout. It has been resolved when I use polling in usb intterupt . thank

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Einar Thorsrud — Tue, 16 Apr 2019 05:48:17 GMT

Hi Nandi,

The problem is that long writes takes longer time than what has been allocated to the flash write by the internal scheduler in the SoftDevice. Splitting long writes into multiple shorter once should be an acceptable workaround in most case. There is nothing else you need to consider, other than things like not accessing the NVMC directly when using the SoftDevice, but that is unrelated to this issue.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Nandi — Mon, 15 Apr 2019 13:42:44 GMT

I also found the same issue, using s340 6.1.1. What do I have to do to use flash when enabling softdevice? This is a very serious issue for the products we are developing. The current product cannot continue to do so.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Einar Thorsrud — Fri, 09 Nov 2018 13:54:28 GMT

Hi.

It is not fixed in 6.1.1.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

hathach — Fri, 09 Nov 2018 12:57:25 GMT

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

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Einar Thorsrud — Mon, 05 Nov 2018 08:29:50 GMT

That sounds good. I have created an internal bug report so that it can be fixed in a future SoftDevice release.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

hathach — Fri, 02 Nov 2018 16:42:07 GMT

Thanks, I am glad that you could reproduce it. Was thinking it is my code doing incorrectly. Please take your time, I divide it into 2 writes ( half page each) as walkaround, seems to be OK for now.

github.com/.../flash_nrf5x.c

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

Einar Thorsrud — Fri, 02 Nov 2018 14:47:54 GMT

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.

RE: sd_flash_write() cause NRF_FAULT_ID_SD_ASSERT

hathach — Fri, 02 Nov 2018 12:44:56 GMT

new found, if I seperate the whole page write (1024 words) into 2 x 512 words, it does seems to work. This is a workable walk-around, but I am still interested on why S140 v6.1.0 assert, it should be able to handle up to a page write according to the specs. hmmm. Did I miss something !!!