This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442 number of byte transferred by BCDMA, EOL for PDMA

Hello, 

My question is a little detailed about the BCDMA use and its low-level register settings. But My questions are important because it seems that this is not behaving as I'm expecting. Specially my 4th question is very important to be addressed as the byte counts provided don't make sense

I am using the example that is provided in the following link to use the UART with BCDMA:

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1215616/questions-about-dmss-bcdma-pktdma-and-pdma/4597533?tisearch=e2e-sitesearch&keymatch=uart_rx_dma%2525252520bcdma%2525252520example#4597533

In this example it uses a pin-pong buffer, so first BCDMA uses a ping buffer to fill the received data from UART, then when it reaches the end of the EOL that is defined by icnt0=128 bytes, there is an event happening, so the CPU can access the ping buffer and during this time BCDMA will fill the pong buffer, and vice vera. The UART trigger level is 1 byte, so as soon as it receives a byte, it triggers the DMA so which transfers it to the RCP buffer of PDMA which is 128 bytes, where the z count for that is defined as 128 bytes, meaning that when it reaches to the water level of 128 bytes, it will trigger the PSIL Tx bus to transfer it to the BCDMA. 

In this case, no trigger for BCDMA is set, and it uses the normal  bcdma_rx channel where the capacity of a channel is 64 bytes.

By running the example what I see is that when I input the first 64 bytes on the UART console, it transfers it to the final destination buffer (defined by SW), meaning that when BCDMA gets full (64-byte rx channel) it transfers the 64 bytes. 

  1. Here it seems that it doesn't wait for the PDMA RCP buffer to get to its EOL (128 bytes) to transfer it to the BCDMA. Probably it's because the changes that it is asked to be done on page 10 of the PowerPoint provided in the zip folder are not implemented. In the PowerPoint, it has asked to change a source file for the UDMA driver and rebuild the library. I assumed if I change the source file, the library will be rebuilt but it seems it's not the case and it uses a pre-built library. How can I do it? 
  2. Also in this case I see 64 bytes are transfered together. Does it mean that when there is no trigger defined for BCDMA (like this example), the BCDMA starts transferring when it receives more data to transfer when the FIFO for its channel is full?
  3. I tried to change the channel capacity, by changing chType from UDMA_CH_TYPE_PDMA_RX to UDMA_CH_TYPE_PDMA_RX_HC. But it doesn't accept it and the software fails. Why I'm not able to do so? Is there any other configuration that needs to be done?  
  4. When the BCDMA is transmitting to my final SW destination buffer, I'm expecting to be able to see the number of bytes transferred completely, the number of bytes that started to be transferred, and the packets that are completed through monitoring the following registers from table 11-238.bcdma_rchanrt in the AM64x TRM revision 2.0. The initial value for these registers is 0. When the 64 bytes are transferred, I can see that the value for the number of bytes transferred is 64, but after it reaches its EOL (128 bytes), these three registers constantly increment despite I don't enter any UART input. What is the reason for that? I like to have the pointer to the last address that was written by DMA so that I can use it as a circular buffer that the SW and DMA can both access and we can keep track of the In_Ptr and Out_ptr to observe in case overflow happens.  Or at least has the number of bytes transferred so far to my destination address? 
  5. There are no descriptions for the registers DMASS0_BCDMA_0_RCHANRT_peer0_j ... to DMASS0_BCDMA_0_RCHANRT_peer15_j. But it seems some fields of them are keeping the bytes of the data that is received by PDMA and some others of them are keeping some constant values that might be some configurations. But I like to have more information regarding these registers. 

Thanks, 

Boshra