SOFTDEVICE: ASSERTION FAILED PC=0x00000A60

[CodeVader]

Hi,

Application details:

I have a datalogger application that samples data every second. It uses the following modules:

TWIM0 -> To communicate with external RTC clock via I2C.

TWIM1 -> To send data to external display via I2C.

SPIM2 -> To get data from an external ADC with sensor.

QSPI -> To save data to an external memory.

I use BLE central to scan and connect to another custom peripheral device using long range PHY. I send all the data every 10 mins to this device which works as a router.

Everything works correctly most of the time. The application continues to sample when the data is being sent simultaneously.

Issue:

I get a SOFTDEVICE: ASSERTION FAILED that happens inconsistently about 5 to 10 times a day when the BLE central is sending the data. You can see the call stack and PC in the attached picture.

I am using nRF SDK v16.0.0 with s140_nrf52_7.0.1_softdevice. Could you please help me with this issue?

[Einar Thorsrud]

Hi,

You write th t you get a SOFTDEVICE: ASSERTION FAILED but I do not see the relevant address for that. Can you double check to verify that you actually see a SoftDevice assert and get the PC from then? (There is no SoftDevice assert for S140 7.0.1 at 0x00000A60).

[CodeVader]

Hi Einar,

Thanks for getting back to me. I usually see SOFTDEVICE: ASSERTION FAILED after I click on continue running the code. Although, this time I got this error as shown in the attached picture.

I will try and recreate this issue today and get back to you with a screenshot of the SOFTDEVICE: ASSERTION FAILED.

Any idea as to why the softdevice paused the code based on the previous screenshot? I'm guessing the issue was caused at 0x00020D48.

[Einar Thorsrud]

Hi,

Thanks for the info, and good to hear you found out how to make the sniffer trace. We look forward to getting that.

CodeVader said:

1. I am not sure what encoding it uses, where can I find this information?

As I see from 3 that you are using the SoftDevice in both ends, so then you are using S=8 (it does not have APIs for sending S=2, but it can receive S=2 packets sent by a peer that use it).

CodeVader said:

2. Please see the log below for successful connection:

Thanks. I do not see a log indicating data length update (DLE), but as I don't know your code I cannot see if you do any logging when that (potentially) happens (on the BLE_GAP_EVT_DATA_LENGTH_UPDATE event)? We will also see this from the sniffer trace when we get it, though.

[CodeVader]

Hi Einar,

I think I was able to solve this issue. I was using connection interval 7.5mS (min and max) for the peripheral device. This was probably causing the central devices to assert when the distance was increased. I changed the connection interval to 50mS (min and max) for the peripheral, and I do not get this issue anymore.

I didn't have much luck with the sniffer as it kept losing the connection packets, although the dataloggers and router were still connected. Hence, I was unable to get a sniffer trace for when the issue happens. Please see the attached sniffer trace that I was able to get with the 50mS connection interval.

I am planning to connect at least 5 dataloggers to the router. Please let me know what would be the best connection interval to use for this, or how I could calculate it for coded PHY.

Thanks for all your help.Sniffer_output.pcapng

[Einar Thorsrud]

Hi,

It is interesting that you no longer see this issue with a 50 ms connection interval. I do not have an explanation for that atm, though. In order to try to understand the issue it would be good to have a sniffer trace from close to the central as well. Also, if you do (legacy) pairing wile sniffing, the sniffer will be able to decrypt the encrypted packets.

None of the parameters below (from your attached sdk_config.h should cause an ASSERT, but they look unexpected and/or sub-optimal, in particular:

#define NRF_SDH_BLE_GAP_DATA_LENGTH 251
CODED PHY on the SoftDevice does not lead to any transmissions greater than 27. Having a data length of 251 may however be desirable for other use-cases, like firmware upgrade of 1Mbps/2Mbps.

#define NRF_SDH_BLE_GAP_EVENT_LENGTH 320
This will give a scheduled event length of 1.25*320 = 400 ms. Assuming that intervals are "big" ( > 400ms) this means that a connection may be blocked out by another connection for 400 ms, which may even be beyond the supervision timeout. Having a long event length may however be desirable for other use-cases, like firmware upgrade.

CodeVader said:

I am planning to connect at least 5 dataloggers to the router. Please let me know what would be the best connection interval to use for this, or how I could calculate it for coded PHY.

First of all a key point is that only the central has anything to say on the scheduling (peripherals can request connection parameters to change etc.), but has nothing to say on the scheduling. So you to get good multilink performance the router (which has multiple links) should be central and the datalogger peripherals (which only has one link). Then the router can ensure that the links are properly scheduled next to one another and do not overlap. You also need to think about the event length and connection interval. With all links equal, you should ensure that the connection interval is at least longer than the sum of event length (or multiple if all are the same).

There are also things to consider with regard to connection interval. For instance, longer intervals means longer latencies. But you can also fit longer event lengths which allows you to send more data without the extra overhead you get with more short events compared to fewer long events. On the other hand, retransmissions always happens on the next event, so if you have a lot of packet loss for some reason, shorter intervals and event lengths might give you better throughput, for instance.

Update:

I discussed this issue with the SoftDevice team, and they do not believe adjusting the connection interval to 50 ms will have fixed the issue, just reduced the likelihood / frequency of it occurring. We have not been able to reproduce it ourself yet, so we wonder if you can do a bit more testing to narrow this down? Particularily, we wonder if you can test with NRF_SDH_BLE_GAP_DATA_LENGTH set to 27 and using 7.5 ms as connection interval. Do you still get the assert in that case?

[CodeVader]

Hi Einar,

I have sent you a private message with a sniffer trace, with bonding disabled, and the devices close to each other. This uses 7.5mS connection interval, with NRF_SDH_BLE_GAP_DATA_LENGTH still set as 251 and NRF_SDH_BLE_GAP_EVENT_LENGTH set as 320.

Again, I couldn't capture an assert as the sniffer does not capture the connection consistently when the router and datalogger are at a distance of > 10 m. The sniffer dongle LED turns red and the capture stops when the connection does start getting captured. I have tried this with the sniffer close to the router and the sniffer close to the datalogger.

Unfortunately, I need to keep the router as the peripheral and the datalogger as the central. This is because the connection needs to be initiated from the datalogger.

I will start a test tomorrow and let you know the results of setting NRF_SDH_BLE_GAP_DATA_LENGTH to 27 with connection interval at 7.5mS. I have no issues so far with this setting. I will let this test run for 2 days to make sure no ASSERTs occur.

[Einar Thorsrud]

Thanks for the trace. We look forward to hearing the results of the test with NRF_SDH_BLE_GAP_DATA_LENGTH set to 27 and 7.5 ms connection interval.

Regarding needing to keep the router as peripheral, note that you could also control connection in another way by making the datalogger act as a peripheral, but only do connectable advertising when it wants to connect. Of course there are other factors that may play in, like if one of the roles are connected to mains or a very large battery, and the other is more low power, as scanning is typically more power hungry than advertising. In any case neither way is "wrong" per se, but the scheduling works much better when the central is the one with multiple links. With your topography, each central handles the schedule of each link independently, so you should typically expect more and more overlaps of connection events as the number of concurrent links increases.