Hi all,

I'm operating a DA14580 in the external processor configuration. It is controlled by a uC (SPI master) using the GTL 5-wire SPI protocol. I keep having the problem of running into a deadlock. When streaming some data over BLE (hence a lot of traffic between the uC and the DA), I run into a state where both the DA and the uC want to transmit at the same time. More specifically, the DA gets stuck in the spi_hci_write_func() function. It drives the DREADY signal high and waits for an SPI transfer (spi_wait_for_transfer()):

...
spi_dready_high(); // Assert dready to request transmit
do {
spi_wait_for_transfer(); // Wait for SPI transaction from SPI master device
...

However, the uC tries to send a message at the same time and gets stuck in the spi_send_hci_msg() function, waiting for the DREADY signal to go low:

...
// disable dready interrupt
dready_irq_disable();
// Polling DREADY to detect if data is being received
while(dready_get_status());
...


The following happens:
- The uC disables the dready interrupt, just before the DA asserts the dready signal.
- The dready signal goes high, but no interrupt is triggered on the uC side.
- Instead, the uC waits for the dready signal to go low.
- The dready signal won't go low, since the DA is waiting for an SPI transmission.
--> Deadlock

I'm wondering how the protocol intends to avoid running into the deadlock described above. From what it looks like there is no mechanism that prevents that situation.

Thanks!
mabraun

edit: tried to make problem description more comprehensive