The next stage is to send a sequence of uint16 size data to the LPSPI via DMA and obtain the replies for each.
I note that the transmit and receive FIFOs are 4 deep, plus the Transmit/Receive data register.
I have a configuration where I can send up to 5 uint16 data values via DMA to the bus. As mentioned in my previous question, I am using channel-linking between 2 transfer control descriptors as follows:
TCD takes data from an array in memory, and pokes it into the TDR. Source address is incremented by 2, and its CITER is decremented (and would be non-zero). The TCD then links to the next channel.
TCD reads data from RDR and pokes it into a receive array. Its CITER is only 1 transfer, so it terminates here, but it increments its destination address and links back to TCD.
This process continues until the CITER on TCD is zero, as such many transfers can take place depending on the initial BITER value of TCD.
With the next scheduled run of the code, software simply puts the array pointers back at the beginning of the arrays, sets the transfer BITER and CITER for this execution period, and then makes a DMA request and starts.
On other NXP devices with DMA and SPI peripherals, the DMA requests are schedued based on whether the transmit FIFO is full and whether the receive FIFO is drained. Accordingly, the DMA engine is able to many transfers into the peripheral without any further intervention.
It appears on the S32 that there is no way to have the DMA requests pause when the TX FIFO gets filled to allow the SPI engine to catch up. I can see 5 correct data items being presented to the bus, but no more than that - i.e. if I have 20 items of data to send, I can only see 5 of them presented to the bus.
What is the correct procedure to have the DMA engine move this data into the peripheral?