BLE event notifications stop after a Dropped packet during serialization comms between Nordic and an NXP CPU

[Declan Traill]

Hi,

   I have a Serialization connection working between a Nordic nRF52 CPU (slave) and an NXP CPU (master), using SPI.

The NXP is starting/stopping a BLE Scan on the Nordic every 4 seconds, and when Scanning is active, the Nordic is streaming back Advertising reports to the NXP CPU via the SPI Serialization connection.

This is all working fine for maybe 30 minutes at a time, until the Nordic, for some reason, receives a malformed packet which is then Dropped.

However, after this happens, all the advertising reports completely stop, but the Serialization commands from the NXP to start/stop scanning continue to be processed every 4 seconds with no error codes.

If I allow the default Error Handler in the Nordic to Reset the Nordic CPU when it gets the malformed packet, then it starts up again ok, but I don't want to reset & would like to recover and continue so that any BLE connections to the Nordic CPU are not lost.

If I re-issue the following command after the malformed packet & advertising event have ceased, I still don't get any Notifications of events.

    // Register a handler for BLE events.

   NRF_SDH_BLE_OBSERVER(m_ble_observer, APP_BLE_OBSERVER_PRIO, ble_evt_handler, NULL)

Here is a screenshot of the debug on the Nordic CPU when the Packet is Dropped (after which advertising report events cease), but command processing continues as before:

What could be going wrong? and how to recover the normal operation without having to completely reset the Nordic CPU?

[Declan Traill]

I tried experimenting with those timing values, and found that I can improve it (but not completely fix it) with these numbers:

    init_params.pre_delay      = 0;
    init_params.post_delay     = 2;
    init_params.frame_delay    = 0;
    init_params.transfer_delay = 0;

It would be a great help to know what the actual requirements of the Nordic CPU are regarding these...??

Thanks...