FDS_GC causes hard fault

[brett_anderson]

I'm using SDK 16.0, Soft device 340 v6.1.1, chip nRF52833. Currently no bootloader loaded, but I do use the secure bootloader with light mods. BLE stack and ANT stack are disabled when this occurs. System is basically idle.

This is quite odd. This has been working fine up until this morning, and now I have not been able to solve it. As soon as fds_gc is called, I get a hard fault. I'm using fds with the sd backend. The writes/updates all work fine, but as soon as I call gc, fault.

The PC reported in app_error_weak is 0x5450, which is definitely in the softdevice. The id is 1, so soft device assert failed.

[I read a post that said the actual calling function was in the stack, SP + 0x14. I checked that, and the address is also in SD space: 0x2C331] 

Can anyone tell me what assert is at 0x5450(or 0x2C331)? I've been using this setup for multiple projects, and no idea why this one just went south. I'm sure it is something dumb, but beating my head against the wall. Just knowing what assert failed would probably give me the answer.

I'm not writing that much data. I have two records, one is settings(40 bytes) and one is some statistics(72 bytes). All aligned properly. The records initialize fine. When the first statistic gets incremented, and the system is idle it attempts to update the record. This is successful. In the event call for the fds, on success a flag is set that gc is needed. When the system is idle, it tries to call gc. Instant hard fault.

Relevant SDK configs:

virtual pages: 5

virtual page size: 1024

using sd backend

fstorage max write size: 1024

fstorage max retries: 16

max users: 4 (only using 1 though)

Appreciate any insight!

[Einar Thorsrud]

brett_anderson said:

Is there a reason that the soft device would assert instead of just returning FDS_ERR_TIMEOUT?

The SoftDevice assert happens when it runs and sees that more time has elapsed than what it scheduled (so typically it would have missed a BLE or ANT event, or other task that should have allready been performed). If for instance the flash.

brett_anderson said:

I have no problem dropping the max write size down to 256, and allowing it to use multiple cycles to complete the update/gc. Maybe the default should be way lower than 4096?

Yes, I believe that the value should be lower in case you write large chunks of data. This has been an issue before as well, where long flash operations would cause SoftDevice asserts. Perhaps you are also seeing the limitation that "Flash write operations may exceed the timeout provided when performed with certain protocol operations (e.g. ANT Continuous Scan)."?