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.

UDMA DEMO Question

Hi,

I am using TM4C123BH6ZRB/LM4F212H5BB with IAR Embbeded Workbench and I looked at uddma_demo from TivaWare_C_Series-2.0.1.11577\examples\boards\dk-tm4c123g\udma_demo. I am curious on the way this chip invoke the ISR. According udma_demo, UART0IntHandler() is called when the UART0 DMA transferred is completed. However in the non-DMA interrupt model, the same vector calls UART0IntHandler() when there is data triggered in FIFO. If this is correct, in DMA mode how does this chip generates UART0 FIFO intterupt to DMA engine?

In my device, I am not interesting in using memory-memory DMA transferring therefore I am ignoring uDMAIntHandler() in udma_demo.

The reason we are asking is we are facing and SPI issue. This chip is very busy serves ADC ISR. By the time that SSI0 Slave Rx interrupted, the SPI Rx FIFO already over-ran. We used uma_demo to implement SPI Rx DMA and hope for DMA can pull the FIFO quicker than the non-DMA. However, I ran into SSI0 DMA bus error.

If I turn the ADC data processing off, the SSI0 DMA bus error goes away. With other manufacturer micro-controller, there is a separate DMA interrupt vector for DMA transferred is completed. I am not sure why this TM4C123BH6ZRB/LM4F212H5BB any different. Please help to clarify.

Thanks,

Dennis Nguyen

  • Dennis Nguyen47496 said:
    I am curious on the way this chip invoke the ISR. According udma_demo, UART0IntHandler() is called when the UART0 DMA transferred is completed. However in the non-DMA interrupt model, the same vector calls UART0IntHandler() when there is data triggered in FIFO. If this is correct, in DMA mode how does this chip generates UART0 FIFO intterupt to DMA engine?

    Section 9.2.10 Interrupts and Errors of the TM4C123BH6ZRB datasheet contains the following which explains that:
    Depending on the peripheral, the μDMA can indicate transfer completion at the end of an entire transfer or when a FIFO or buffer reaches a certain level (see Table 9-2 on page 588 and the individual peripheral chapters). When a μDMA transfer is complete, the μDMA controller generates a completion interrupt on the interrupt vector of the peripheral. Therefore, if μDMA is used to transfer data for a peripheral and interrupts are used, then the interrupt handler for that peripheral must be designed to handle the μDMA transfer completion interrupt. If the transfer uses the software μDMA channel, then the completion interrupt occurs on the dedicated software μDMA interrupt vector (see Table 9-6 on page 599).

    Dennis Nguyen47496 said:
    However, I ran into SSI0 DMA bus error.

    The datasheet says the DMA controller will set the ERRCLR bit if "controller encounters a bus or memory protection error as it attempts to perform a data transfer". Don't understand why the ADC data processing would cause a DMA bus error. When the DMA bus error has been reported, do the DMA controller registers and DMA Channel Control Structure (in RAM) look correct?

  • Hi Dennis,

         From the link below download the workbook pdf. There is a portion that discusses udma_demo. Maybe, some of your questions will be answered. 

      http://processors.wiki.ti.com/index.php/Creating_IoT_Solutions_with_the_TM4C1294XL_Connected_LaunchPad_Workshop

        Post your, SPI DMA code here. So, others can review it. Also, do a search with similar posts here and at Stellaris forum. I remember someone posting a working code of SPI DMA.

    -kel

  • Chester Gillon said:
    do the DMA controller registers and DMA Channel Control Structure (in RAM) look correct

    I configured the SSI DMA in Configure_uDMA() in the attached file. As far as I know it is correct per the udma_demo. Do you want me to dump the 1024 bytes of the control table from RAM?

    Thanks,

    Dennis

  • Hello Dennis,

    The reason behind the interrupt being mapped via the peripheral interrupt is that if an error condition occurred on the peripheral side, e.g. UART has parity error, I2C has arbitration lost, the CPU will not have to process to interrupt handlers, but instead in the peripheral interrupt handler come to know that while DMA completed the data may not be correct as an error condition occurred.

    Secondly with the uDMA faulting when ADC is operational and not faulting when ADC is disabled would mean that the ADC Data being read was over-written into the SRAM memory where the control table is mapped. Hence the dump of the memory locations holding the control table would tell us if the task entry for uDMA was over-written

    Regards

    Amit