Page 1 of 1

AI Deck Uart 1 TX DMA conflicts with bmi088_spi

Posted: Thu Jul 08, 2021 4:03 pm
by freiremelgiz
Hello,

I am trying to use DMA with the uart1 (USART3) interface to send data between the AI Deck 1.1 GAP chip and the Crazyflie2.1 (firmware side).

I am successful at sending/receiving using the uart1.h interface provided without DMA. However, when I set -DENABLE_UART1_DMA, I get a redefinition linking error when building: DMA1_Stream3_IRQHandler function is defined both in uart1.c and in ~/src/drivers/src/uart1.c and in ~/src/hal/src/sensors_bmi088_spi.c. The uart1.c source code has the following comment, however:

Code: Select all

/** This uart is conflicting with SPI2 DMA used in sensors_bmi088_spi_bmp388.c
 *  which is used in CF-Bolt. So for other products this can be enabled.
 */
//#define ENABLE_UART1_DMA
Since I am not using the CF-Bolt, I was hoping I could use DMA for TX in USART 3.
Refer to the attached image for a visual table of the interfaces that are trying to use the DMA resource.

Furthermore, I was successful in configuring DMA to handle USART3 RX operations in my own file separate from uart1.c and this feature works. However, I also need the TX operations with DMA because I have the following issue with the non-DMA uart1 interface: When I send 16 Bytes via UART in the controller loop, everything works. However, when I increase the packet size I send to 20 Bytes, the Kalman rate supervisor tells me it is slow (94-95 range). I have determined that this delay is originated in the uart1.c for-loop:

Code: Select all

void uart1SendData(uint32_t size, uint8_t* data)
{
  uint32_t i;

  if (!isInit)
    return;

  for(i = 0; i < size; i++)
  {
    while (!(UART1_TYPE->SR & USART_FLAG_TXE));
    UART1_TYPE->DR = (data[i] & 0x00FF);
  }
}
And I would like to use DMA instead of this for-loop to do the transfer of data.

Is the DMA1_Stream3 being used by the Crazyflie2.1 (for example by the bmi088_spi interface)? If not, I would appreciate a bit of guidance on how to modify the code so that the resource (DMA1_Stream3) is freed-up for USART3 TX use.


Thank you for your time and help,

Victor Freire
University of Wisconsin-Madison
freiremelgiz@wisc.edu

Re: AI Deck Uart 1 TX DMA conflicts with bmi088_spi

Posted: Thu Jul 15, 2021 2:46 pm
by arnaud
I you will never use this firmware on a bolt and you do not mind forking crazyflie firmware you could 'just' comment-out the interrupt in sensors_bmi088_spi_bmp388.c. It will not cause any problems as long as you do not use a bolt.

A cleaner solution might be to re-route the interrupt. Declaring the interrupt in src/drivers/src/nvic.c and adding a function to set the location of the interrupt using a function pointer. This way the BMI driver can set the interrupt address at runtime and so can your app. For the details, it should likely assert(false) if no pointer is set as well as return an error or assert(false) if a pointer is attempted to be set twice. This is something that would be possible to merge-in if you are interested in keeping the firmware stock.

Re: AI Deck Uart 1 TX DMA conflicts with bmi088_spi

Posted: Sun Jul 18, 2021 2:02 pm
by freiremelgiz
Thank you for the response. Commenting the interrupt in sensors_bmi088_spi.c worked. I can now use DMA for both TX and RX with USART3 communication between AI Deck and Firmware.

The fork I am working on is too far from stock at this point, but if some day we consider trying to merge some of our changes, I will keep the cleaner method in mind.

Thank you, again,

-Victor

Re: AI Deck Uart 1 TX DMA conflicts with bmi088_spi

Posted: Mon Jul 19, 2021 9:35 am
by arnaud
No worry, good that it worked!

About merging: we have been working at making that easier by allowing out-of-tree app and deck drivers. The intent it to allow keeping the very custom code separated from the core code. When you get around to look at merging, might be a good way to go. Tell us if there is any more infrastructure required, this is still work in progress but it is something we would really like to improve.