fix(PeriphDrivers): SPI RevA1 DMA Handler Fix

[BrentK-ADI]

Fixes multiple potential issues with the SPI DMA handler which could cause SPI transactions to falsely get callbacks and terminated, or some transactions to never get callbacks or terminate under various conditions.

Failure Condition 1:

If there are 2 active SPI peripherals using DMA (for the example say SPI0 and SPI1). If SPI0 is currently being configured via MXC_SPI_RevA1_MasterTransactionDMA and the DMA interrupt occurs for SPI1, it is possible for the interrupt to be handled as if SPI0 was the source, causing SPI1 to never complete.

This only occurs when the DMA interrupt happens between reassigning the state's req, and before clearing req_done

msdk/Libraries/PeriphDrivers/Source/SPI/spi_reva1.c

Line 709 in 2ec3f4e

states[spi_num].req = req;

states[spi_num].req = req;
states[spi_num].started = 0;
states[spi_num].req_done = 0;

The since .req is not NULL the DMA handler will look at the channels for that req. None of the channels match, but since the req_done is still 2 from a previous transaction (not yet cleared) the callback will happen (erroneously) and the loop breaks, never actually touching the real SPI peripheral causing the interrupt, resulting in the SPI transaction going stale and never getting a callback.

Failure Condition 2:

Similar to the above, if the SPI instance passes the NULL check for req, but its channels don't match, the if statement still hits. If that transaction is Tx or Rx only (i.e. txrx_req == 0), the if statement will pass, once again falsely sending a callback, and causing the real cause of the interrupt to go stale.

Solution

There probably should be some critical section code for working with the states array. However a simple work around is to just continue processing the loop if there is not a DMA channel match. For applications which leverage the MSDK without this fix, disabling interrupts in the user code while the MasterTransactionDMA is being called also mitigates the issue.