This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Softdevice assert: 154516:0

SDK16.0.0 + Mesh SDK 4.1.0

Help, we have developed our own board with a Fanstel BT840X module. Some of our boards are asserting ("Softdevice assert: 154516:0") and I am trying to figure out why. The same identical firmware seems to run fine on about half of our boards (going for days) and some crash after a few minutes or hours.

It might be temperature related, but I can't be 100% sure. Putting the crashing sensors in a 0degC chamber seems to stop the crashing.

I put a breakpoint in the app_error_fault_handler(), but I don't know what to do after that.

The chips on the module are rev2 (QIAAD0) made in date code 1926AH.

Thanks.

Parents Reply Children
  • Yes, I think so too, but so far the only thing I was able to find wrong with our hardware is that we did not connect VDDH to VDD. VDDH is just floating. Could this cause a Softdevice assert?

    What hardware issue could cause a Softdevice assert?

    Thanks.

  • Hi,

    According to the product specification, this will cause unspecified behavior. So not really sure if this is the cause for the issue but you shouldn't have VDDH floating. Connect VDDH to VDD and see if it helps.

    Best Regards,

    Martin

  • We got the new boards that have VDDH connected to VDD and they are still crashing.

    I've since updated to SDK17.0.2 + Mesh SDK 4.1.0 + S140_7.2.0

    With the new Softdevice the assert has changed to 154632:0, Does this number tell you anything?

    My test setup consists of 8 boards that have subscription and publication groups. One of them is connected to our iPad app as a proxy and forwarding the messages through. Each node sends a message every ~3 seconds. So far I've not seen the connected proxy node crash, but only the others. I.e. I take a crashing node and make it the proxy it will stop crashing, but I can't confirm this behavior 100%.

    The odd thing is that not all will crash. Of the 8 boards there are three of them that have not crashed at all and they all running the same load.

    Additional bit of info: One of the eight has been crashing consistently within 10-25 minutes, 5 times in a row. I now have it running in a temperature chamber at 0degC and it has been running for 3 hours. Will leave it in there overnight.

  • Hi,

    Support for nRF5 SDK v17.0.2 and Softdevice v7.2.0 was added in Mesh SDK v5.0.0. Not sure if this is related to the issues you are experiencing but it can lead to unexpected behaviors. If you plan to use nRF5 SDK v17.0.2, I suggest you upgrade the Mesh SDK to v5.0,0.

    Yes, it is definitely strange that only some of your boards are crashing with the same firmware.

    ftjandra said:
    So far I've not seen the connected proxy node crash, but only the others. I.e. I take a crashing node and make it the proxy it will stop crashing

    Have you tried with all of the crashing boards?

    Have you tried with a DK? Do you have any logs from the crashing node? Can't tell much from the softdevice assert.

  • All our problems seem to stem from the 32.768kHz clock on the modules being out-of-spec. As soon as I switched over to synthesizing it from the 32MHz clock the crashes stopped. Ran all the modules for the past couple of days without a single crash.

    Thanks.

Related