AI Deck Uart 1 TX DMA conflicts with bmi088_spi

Firmware/software/electronics/mechanics
Post Reply
freiremelgiz
Beginner
Posts: 2
Joined: Thu Jul 08, 2021 3:43 pm
Location: Madison
Contact:

AI Deck Uart 1 TX DMA conflicts with bmi088_spi

Post 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
Attachments
Relevant DMA Streams
Relevant DMA Streams
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: AI Deck Uart 1 TX DMA conflicts with bmi088_spi

Post 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.
freiremelgiz
Beginner
Posts: 2
Joined: Thu Jul 08, 2021 3:43 pm
Location: Madison
Contact:

Re: AI Deck Uart 1 TX DMA conflicts with bmi088_spi

Post 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
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: AI Deck Uart 1 TX DMA conflicts with bmi088_spi

Post 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.
Post Reply