Got NRF_FAULT_ID_SD_ASSERT on S130 while doing sd_ble_gatts_hvx

[codezork]

When I repeatedly (>290 times) send the same notification to the connected host via sd_ble_gatts_hvx, I get a sd_assertion:

Fault identifier:  0x1
Program counter:   0x104FA
Fault information: 0x0
Fault identifier:  0x1
Program counter:   0x14D98
Fault information: 0x0

The payload is 10 bytes long, using S130 with SDK 12.1 on the PCA10028. sd_ble_tx_packet_count_get always returns 7 and the event BLE_EVT_TX_COMPLETE comes after every notification. I am trying to notify repeatedly a sensor reading to a connected host. The assertion sometimes comes after less readings or more. Can anybody give me a hint on that?

Here is the EmBlitz project: notifytest.zip

Here the Android host project: bluenodes.apk

The oscillogram showing disable_irq/enable_irq activities:

[Trond Einar Snekvik]

Hi, this looks like a timeslot problem, alright.

The go-to solution is usually to increase the end timer margin in the timeslot module. This is already pretty high at 1000ms, but increasing it to 2000 is worth a check.

One trick that could help you identify the issues you're seeing is attaching a logic analyzer or an oscilloscope to your device, and toggle GPIO lines in the _ENABLE_IRQS and _DISABLE_IRQS, like this:

#define _DISABLE_IRQS(_was_masked) do{ _was_masked = __disable_irq(); if (_was_masked) NRF_GPIO->OUTSET = (1 << 0); } while (0)
#define _ENABLE_IRQS(_was_masked) if (!_was_masked) { NRF_GPIO->OUTCLR = (1 << 0); __enable_irq(); }

The IRQ disabling is a common reason for failing timeslots, and there's a possibility that your unusually high gatt traffic is throwing us into some corner case we haven't found in testing.