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]

Further information:  The apparent malformed packet seems to occur a lot more frequently if a small time delay is introduced by (uart debug added) to the 'case SPI_RAW_STATE_RX_HEADER:' state in spi_slave_event_handle() (file ser_phy_spi_slave.c). This code seems to be very sensitive to timing changes - probably as it is processing SPI comms in real time, so bytes can get missed if extra delay is introduced - leading to what appears to be corrupted packet data.

However, the error still occurs occasionally with no extra code added, and the BLE notifications still shouldn't stop if this happens. The packet should just get dropped and everything else continue on normally.

----------------------------

Could there be a difference in the SPI peripherals between the Nordic and NXP CPU's that might be causing timing problems?

On the NXP SPI Peripheral, there are some timing parameters that I can adjust, can you tell me what requirements the Nordic has for these:

    uint8_t                pre_delay;      //**< Delay between SSEL assertion and the first bit - in SPI clocks
    uint8_t                post_delay;     //**< Delay after the last bit and deassertion of SSEL - in SPI clocks
    uint8_t                frame_delay;    //**< First bit stretching on each frame (excluding the first one) - in SPI clocks
    uint8_t                transfer_delay; //**< The minimum time in SPI clocks the SSEL is deasserted between frames

The current settings I have are these:

    init_params.pre_delay      = 3;
    init_params.post_delay     = 5;
    init_params.frame_delay    = 0;
    init_params.transfer_delay = 8;