Random NRF52840 (A silicon) failures

[bkdrock]

Every once in a while I will get a failure that results in the app_error_fault_hanlder() being called and the following info:

ID = 1

PC = 0x14550

error_code = 0x495

line_num = 0x400.

I used the nrf_strerror_get() to try to figure out, but it just returns "Unknown error code".

It happens infrequently, maybe a couple of times per day. Can you provide some info on this error?

[Sigurd]

Hi,

When app_error_fault_handler is called with ID=1, then this is a SoftDevice assertion(NRF_FAULT_ID_SD_ASSERT). But normally the info field should have been 0, i.e. no error_code, line_num or p_file_name should be present.

What SoftDevice version are you using?

[bkdrock]

I am using s140_nrf52840_6.0.0-6.alpha_softdevice.

[Sigurd]

Ok, I will look into the program counter of the instruction that triggered the fault. 

Is the PC value always 0x14550 when the failure happens? or is it a new PC value each time?

[bkdrock]

Yes, I have hit it multiple times, and that has been the value. 

[Sigurd]

Was the error_code and line_num also always the same? What about p_file_name?

Was the compiler optimization set to 0 when you tested this? If not, could you try to reproduce the issue with optimization set to 0 ? and with the Preprocessor symbol DEBUG defined.

EDIT: The instruction that caused the assert in the SoftDevice have been found. I will look into possible reasons for why this is happening, and get back to you.

[bkdrock]

OK, I set the optimization to 0. When I hit the breakpoint this time (in app_error_save_and_stop()) I get:

ID=1

PC=0x14550

but

info=0

So the line_num and p_file_name, which are derived from info, are not valid. 

[Sigurd]

Hi,

The assert you are getting is happening because the SoftDevice have either not had enough time to process a LL event, or that it has been blocked in a higher priority interrupt. The processing of LL events is something that have been improved in the production release of the S140. The SoftDevice team believes that migrating to the S140 v6.0.0 (production release) will solve the issue.

Now that the production release of the S140 is released, it is also on a general basis recommended to migrate to the production release.

Also note that SDK 15.0 have been released with support for S140 v.6.0.0.