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.

UART TX DMA done interrupt always 1

Other Parts Discussed in Thread: CC3200

Hello everyone,

Board - TM4C1294XL


Well I came across a problem which I cannot get around in any way. The problem has to do with the DMATXRIS on the UART, raw interrupt to the DMA transfer done to the UART TX and it never clears.
Every time I enable the DMA for the TX FIFO that behavior occurs. Like this:
UARTDMAEnable(UART0_BASE, UART_DMA_TX);

I simplified the code to seek the problem to no avail. The DMA initialization function is not called for the test code I am using to seek the problem. I did try with the DMA initialized before the Init_UART0() function- 
Right now I have the main() doing:

  1. setting the clock to 120Mhz
  2. Initializing the systick (interrupt every 1ms)
  3. Calling Init_UART0().

My Init_UART0() can be seen bellow:

void Init_UART0(void)
{
	MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
	MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    MAP_GPIOPinConfigure(GPIO_PA0_U0RX);
    MAP_GPIOPinConfigure(GPIO_PA1_U0TX);
    MAP_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
	//MAP_UARTConfigSetExpClk(UART0_BASE, ClockFreq, 115200,
	//		(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |UART_CONFIG_PAR_NONE));
    UARTStdioConfig(0, 115200, ClockFreq);


	MAP_UARTFIFOLevelSet(UART0_BASE, UART_FIFO_TX4_8, UART_FIFO_RX4_8);

	/* 
	 * After this line of code the DMATXRIS always set's to 1.
	 */
	UARTDMAEnable(UART0_BASE, UART_DMA_TX);



	uint32_t flags = UARTIntStatus(UART0_BASE,0);
	MAP_UARTIntClear(UART0_BASE,flags);
	//MAP_UARTIntEnable(UART0_BASE, UART_INT_DMATX);
	/* */


	UARTIntRegister(UART0_BASE,UART0_Handler); // não há MAP pelos vistos


	//MAP_IntEnable(INT_UART0);
	counter = 0;
	UARTEnable(UART0_BASE);
}

I also tried the same with the UART1.

I checked the Errata and the datasheet multiple times to find nothing. Could there be a problem with either my board?  Help would be appreciated :)

  • Hello Luis,

    Has the DMA been configured?

    Regards
    Amit
  • Hi Luis,

    First - what a well thought/planned - and very nicely written post.   Good job!

    Your far ahead of me/my group w/this vendor's DMA - but I've concern about the "broadness" of, "UART_DMA_TX."   It seems that if multiple UARTs are "in play" - that parameter may have difficulty in "attaching" to any one specific UART (UART0 in your case) - does it not?   Again - that's the extent of my contribution - and bravo on your writing...

  • Hi Amit,

    I tested once with the Init_DMA() called before and once without.
    Both produced the same result.

    The Init_DMA() configures the channel 9 but,
    It doesn't configure the transfer, only the control.
    It doesn't enable the channel (but it enables the DMA)

    Would you prefer the code?
  • Hi cb1,

    Thanks! I'm trying to break my usually light questions which usually do not help + having a good pre-analysis.

    UART_DMA_TX is inded general. It's a macro from Tivaware itself. It's a macro for the bit value needed to the register that enables the DMA triggers (TX, RX and error)
  • Hello Luis,

    If the uDMA is not configured and a DMA Request is asserted by the peripheral then a DMADONE shall be returned which will trigger the TXRIS.

    Regards
    Amit
  • Hi Amit,

    Thanks for the info.

    Though if the TXRIS is set to 1, clearing it should work right? It never clears, ever.

    Here is the edited Init_DMA();

    I added somewhat of a dummy transfer config + enabled the channel

    void InituDMA(void){
    
      MAP_SysCtlPeripheralDisable(SYSCTL_PERIPH_UDMA);
      MAP_SysCtlPeripheralReset(SYSCTL_PERIPH_UDMA);
      MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_UDMA);
    
      MAP_SysCtlDelay(10);
    
      MAP_uDMAEnable();
    
      uDMAControlBaseSet(pui8ControlTable);
    /*
     * This is for seting up the UDMA_CH_1 for GPIO_BASE_OUTPUT1
     */
      MAP_uDMAChannelAssign(UDMA_CHANNEL_UART0TX);
    
      MAP_uDMAChannelAttributeDisable(UDMA_CHANNEL_UART0TX,
    		  UDMA_ATTR_ALTSELECT | UDMA_ATTR_USEBURST |
    		  UDMA_ATTR_HIGH_PRIORITY |
    		  UDMA_ATTR_REQMASK);
    
      MAP_uDMAChannelAttributeEnable(UDMA_CHANNEL_UART0TX, UDMA_ATTR_USEBURST);
    
      MAP_uDMAChannelControlSet(UDMA_CHANNEL_UART0TX | UDMA_PRI_SELECT,
    		  UDMA_SIZE_8 | UDMA_SRC_INC_8 | UDMA_DST_INC_NONE |
    		  UDMA_ARB_8);
    
      MAP_uDMAChannelTransferSet(UDMA_CHANNEL_UART0TX | UDMA_PRI_SELECT,
    		  UDMA_MODE_BASIC,
    		  g_ui8RxBufA,
    		  (void *)(UART0_BASE + UART_O_DR), 1);
    
      MAP_uDMAChannelEnable(UDMA_CHANNEL_UART0TX);
    
    }

    EDIT:


    I did add this function before Init_UART() so now the DMA is configured before the UART

  • Hello Luis,

    Once the transaction is over, the UART TXFIFO will still be empty. Hence with the DMA enabled, the UART shall still request more data. However since the DMA configuration is not available. it will still give a done. hence the RIS shall not get cleared. On the other hand, when the DMADONE interrupt for TXDMA comes, and if you disable the TXDMA in UARTDMA register then clearing the UARTRIS will take affect.

    Regards
    Amit
  • Thank you Amit,

    Did not find that on the datasheet nor the peripheral driver library. If indeed is there (especially the datasheet) and I was not blind, maybe something to consider to add in the near future if possible?
    Seems like something really important.

    I will try it out!
  • Hi Amit,

    Wonderful (most needed) tech detail, here.   Thank you.

    Yet - I know Luis to be thorough - and motivated - he combs thru & reads/reviews the MCU manual.

    Did he/I/others miss something here - or is this "insider knowledge" beyond the reach/grasp of (all) client-users?

    If so - is that correct/proper?   Can the long awaited "better/more detailed DMA write-up" be scheduled for (faster) arrival?

    [edit] (swear to God - I did not see Luis' writing until mine had completed!)   Great minds (true in Luis' case - not so much mine) think alike.   (hoarding of such critical data may not be best/brightest - and invites the ongoing question - "What else (critical) is buried/hidden/obscured?"   Pity!

    (we know that you don't make those decisions - but really...)

    Forum community - if "ever" a post warranted a "Like"... Punch that button!   Is this not our best (and only) method of encouraging far better "transparency?"

  • So I tested and everything works as expected.

    Since I started working with the DMA, which was what made me really start this method of reading the datasheet, there has been here and there (can't now say it specifically) info that you gave me that seemed to lack in the datasheet. You should have a notebook to write down every DMA question you answer about info that wasn't in the datasheet :p

    Maybe a revision of dma_demo or new examples (plural) should be done and added to Tivaware in the future (add, add ,add, we ask to add so much stuff)

    Thank you very much for your fast and most helpful assistance!
  • Hello cb1, Luis,

    I can confirm that this information is missing in the data sheet. This is one thing we have decided to take up as Application Note(s) for Peripherals and functions which are complex enough that data sheet does not do full and 100% justice.

    Regards
    Amit
  • Ah!

    That's good.
    The Tiva is different from most MCUs I've seen in which there's soooooooooooooooooo much info in the datasheet. Don't take me wrong. I actually like the Tiva Datasheets. Great source of info, learned a lot from them with the initializations and such. It's just that most MCUs have a reference manual and/or specific application or reference manuals for each peripheral. I did have a hard time when I tried other MCUs (I started with Tiva), I always found the datasheets so short on info (little did I know that reference manuals existed), and I did see other users in the opposite situation.

    Interesting, is there already or is gonna be released some application notes for some peripherals?
  • May I suggest that, "full and 100% justice" is "on par" with naming a small, limited econo board, "Launch?"

  • Hello Luis,

    No doubts about the DS. And the newer devices have started changing the DS appearance to be more of a Product Brief and then each section handled separately (CC3200 is one example).

    Planned Application Note (in order of time): JTAG and EPI. Now uDMA comes into the Pipe.

    Hello cb1

    Do you mean a break-out board?

    Regards
    Amit
  • Hi Amit,

    I take advantage of this to speak more of the DMA transfers to the uDMA TX.

    I do not have a "pretty" post like before, I do need to make some more tests for that.
    I was using basic mode, now trying ping-pong mode.
    Enlighten me for I don't remember nor is specifically in the ping-pong description on the datasheet (though could be somewhere else this time I haven't checked again, saying from memory for the rest) what happens if I don't initialize the next transfer. Does the DMA stop and issue a DMA done interrupt?
    I remember before I had problems stopping a DMA ping-pong transfer in the past. I would just disable the channel but I do not want another DMA transfer to initiate at all before I disable the channel.
  • Hello Luis

    If the buffer runs out and it is not initialized then it will keep on giving DMADONE and remain in STOP.

    Regards
    Amit
  • Thank you once again Amit.
  • Hello Luis

    I can trust you to find me a missing piece of data sheet information with that one as well... :-)

    Regards
    Amit
  • Hi Amit,

    I didn't quite understand what you are saying.

    (yay 100k points to Amit)
  • Hello Luis,

    It was a vote of confidence in your ability to find an issue with the DS missing a vital piece of information that I would typically end up overlooking... (Good thing)

    Regards
    Amit
  • I do try
    Thanks for the vote of confidence :D
  • So I don't come here necessarily,

    Could you say that the DMA done interrupt is given when the DMA channel is triggered when no (new) transfer is set?
    So the logic for disabling the UART trigger to avoid repetitive interrupts could apply not only to all other FIFOs (TX and RX) but also any other peripheral trigger?
  • Hello Luis,

    Yes. If the DMA Channel is enabled but not set for a transfer it will give a DONE. Only exception is I2C of TM4C129 which has a Burst Count register that keeps a track of how many more transfers to process. For any other peripheral, lets say timer it has no idea what it is giving DMA request for even when the transfer is over. So it is upto the application layer to make a decision to shut down the source.

    Regards
    Amit
  • Thank you for the clarification Amit and for the heads up on the I2C module.

    That I2C module seems like, at least on the TM4C1294, always module made of exceptions, I don't like it :< (I have still to pick it back up since last time I tried when I started with the TM4C1294 and never could make it work)