STM32 to nRF SPI communication problems after nRF reboot

[bleska]

Describe the bug
The nrf_update_required() function checks whether the STM32 FW embeds newer nRF FW binary than nRF has already installed. The version readout (i.e. info struct with version, hash, etc. info) is performed via SPI interface where STM32 is slave and nRF master. There is data flow control mechanism implemented via GPIO's (i.e. STM32 can request data t be sent for nRF to initiate SPI transfer, nRF can request data to be sent for STM32 to prepare).

When communication problems occur, the nRF is rebooted by STM32 and another attempt is done after ~500ms. While nRF is being rebooted, the STM32 can still prepare Tx data and request its transfer from nRF (e.g. ble_loop()). The request via GPIO's is edge based and it can get easily missed by nRF. After nRF has finished its reboot, it's not aware of any SPI request from STM32. The STM32 implement a systimer which overflows after ~2000ms and another GPIO's Tx request is performed. nRF reacts well after this procedure.

Another symptom of the ~2000ms communication stall is the oveflow of SPI Tx FIFO queue which is 8 elements wide. The code doesn't react on the queue oveflow anyhow. The data is simply dropped.

Firmware version and revision
FW TS7 2.9.5 (even earlier are affected)

To Reproduce
Run the following code (or similar):

nrf_reboot();
systick_delay_ms(500);

nrf_info_t info;

if (nrf_get_info(&info) == true) {
dbg_printf("MCU FW nRF FW version SPI: %u.%u.%u.%u\n", info.version_major,
info.version_minor, info.version_patch, info.version_tweak);
} else {
// Failed to get version
dbg_printf("Failed to retrieve version SPI\n");
}

Expected behavior
The STM32 shouldn't transfer any data to nRF while it's being rebooted.