• State Verified Answer
  • Replies 4 replies
  • Subscribers 75 subscribers
  • Views 4012 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 228874
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SOFTDEVICE ASSERTION FAILED AT 0x00014AA6

nine-fox

HI,

I got the following log while advertising:

SOFTDEVICE ASSERTION FAILED AT 0x00014AA6

Since this address locates at softdevice, I can not know what happens.

Would you please point me out? Thanks

Softdevice s140 6.1.1

SDK 15.3

chip: nrf52840

  • +1

    Hi,

    The assert indicate timing issues in the SoftDevice, where the SoftDevice was unable to process radio events in time, probably related to the advertising. When the radio timing requirements are not meet the SoftDevice will assert. There could be several reasons why the SoftDevice did not process these events in time.

    • You are somehow blocking the SoftDevice in a higher priority interrupt/task/thread, and therefore not giving the SoftDevice enough time to process the events.
    • If this is a custom board, it could be some HW issues with the crystal(s) you are using(clock is not accurate enough, wrong accuracy set or crystal is incorrectly loaded).

    Side note: Engineering A version of the nRF52840 is not longer supported, starting from SDK 15. See this and this link.

  • 0 in reply to Sigurd

    Sounds reasonable. I am using a JLINK debugger while it emits the error. Thanks for your reply!

  • 0

    Hi,

    It seems like I have the same problem.

    Same chip.

    Same SDK version.

    Same Softdevice version.

    Also NRF_FAULT_ID_SD_ASSERT and pc of fault = 0x00014AA6.

    Unfortunately I did not manage to setup the our external 32kHz digital clock source (not a crystal) on XL1 as clock source for softdevice, so I had to take inaccurate RC:

    I have found a way to easy reproduce the misbehavior:

    Running in a loop flash access commands like nrf_fstorage_erase and nrf_fstorage_write while softdevice is enabled (active advertisement is even not needed).

    Additionally I found out, that this misbehavior happens only by using softdevice S140 v6.1.1 and v6.1.0 but not with v6.0.0!

    So, please give me some suggestions, what can be done to make the system stable and avoid these softdevice assertion faults.

  • 0 in reply to Dev_853

    Hi Dev_853,

    I suspect you are running into the same issue as in this post. Proposed workaround for now is to split long writes into multiple shorter writes.

Related
Terms of service