DA14581

Consider a scenario where the master and slave negotiate a supervisor timeout of 20 seconds. The slave has code to explicitly disconnect if 5 seconds of link inactivity is detected (prior to the supervisor timeout) via observing the sequence of these events in rwble.c:

/*Last BLE event. Used for application's synchronisation with BLE activity */
typedef枚举
{
BLE_EVT_SLP,
BLE_EVT_CSCNT,
BLE_EVT_RX,
BLE_EVT_TX,
BLE_EVT_FINETGTIM,
BLE_EVT_END,

}last_ble_evt;

I have DA14581 functional spec that indicates that this chip supports BLE v4.1. A newer version of the spec (and the webpage summary) for this part indicates BLE v4.2:

"The DA14581 supports a flexible memory architecture for storing Bluetooth profiles and custom application code, which can be updated over the air (OTA). ...The transceiver interfaces directly to the antenna and is fully compliant with the Bluetooth 4.2 standard."

Hello Dialog,

Is there a (simple) way to determine how many advertising packets (triplets) have been emitted since the chip was powered up? I believe I could watch the event transitions defined by arch_rwble_last_event in rwble.c, but I'm wondering if there is a simple counter that I could access instead?

Thanks!

Hello Dialog,

Some of our devices are occasionally suffering hardfaults. From diagnostic data collected from the device, I understand that I can determine the address of faulting instructions via the saved PC. Is this true, or is the PC at the time of the fault actually the instruction AFTER the faulting instruction? The reason I'm asking is that the PC points to a MOV instruction, which follows a LDRB instruction. LDRB seems much more likely to cause a hardfault.

Thanks!