In looking through the new hal uart dma driver in Ble stack 1.3, I noticed a bug work-around has been introduced (_hal_uart_dma.c):
/* Used to walk the dmaCfg.rxBuf[] one byte per polling pass as a work-around for the case when
* full-duplex traffic using Rx & Tx DMA running simultaneously.
* Although not captured in this UART by DMA case, the _hal_uart_spi.c was able to show that the
* immediate buffer area around the spiRxIdx consists of "cleared" uint16 values,
* but 10-16 indices ahead, there are valid SPI packets ready to be parsed.
*/
static rxIdx_t uartRxBug; // Pre-emptive (not empirically determined necessary) use from SPI case.
I am not using the hal_uart driver, I have written my own dma driver, but I *do* experience the issue of dropping messages when using full duplex. I am working around the issue by doing half-duplex for the time being, but would like to utilize full duplex. Can anyone explain the bug and work-around for me? It is not at all clear from the code.
Thanks
-Tyler