UART EDMA3 transfer and secondary/missed events

Paul,

Welcome to the TI E2E forum. Be sure to search the forum for similar questions, you may find questions you did not realize you needed to ask and they might already be answered; sometimes you will even find your same question already asked and answered. Also, you will want to be familiar with the documentation and support features on the TI website and the informative topics written on the TI Wiki Pages. Good hunting and good luck!

It will often help us in answering your question, if you will provide some specifics such as which TI device you are using, and which versions of tools you are using.

Paul Miller said:

1) What is the best way to initiate a EDMA3 transfer?  I've been able to initiate transfers by a) manually loading the first byte into THR, b) pulling the UART TX out of reset, and c) writing to ESR.

The UART User's Guide should have a section describing the process of using both CPU and DMA transfers to communicate through the UART.

Paul Miller said:

2) What is the best order to initialize EDMA3?  Currently, I enable shadow access via DRAE, set ECR, SECR, ICR, then initialize PaRAMs, and finally enable via EESR.

The best way is to use CSL or the EDMA3 Low Level Drivers (LLD) to do your initialization. The next best choice is to follow any sequences described in the EDMA3 User's Guide.

Paul Miller said:

3) What EDMA3 and PaRAM registers should be set for each transfer, and which can I rely on PaRAM reloads?  It seems that I must re-initialize some registers, even if they're already set, to reliably use EDMA3.  I'm not sure why.

In the Training section of TI.com, there is a training video set for the C6474. Even if it is not the exact same as the processor you are using, it may be helpful for you to review several of the modules. But in particular, the EDMA3/QDMA/IDMA Module will apply to your current questions. You can find the complete video set at http://focus.ti.com/docs/training/catalog/events/event.jhtml?sku=OLT110002 . This and studying the EDMA3 user's Guide should explain how registers are used and how they should be programmed.

Paul Miller said:

4) Should I setup a dummy PaRAM entry to prevent SER and EMR event interrupts?

EMR gets set when a DMA channel is triggered but it has a NULL active PARAM set, with ACNT=BCNT=CCNT=0. This makes sense, because an event occurs but the DMA channel is not ready for it. The right solution is to have the PARAM ready to handle additional data, but for a UART with a limited data burst, a DUMMY PARAM set may be a good choice so that no data is sent or received.

Regards,
RandyP

If this answers your question, please click the  Verify Answer  button below. If not, please reply back with more information.

Hi Randy,

Thanks for answering my post.  I am currently working with the C6748 core of an OMAP-L138 EVM board, and plan to switch to the C6745 in the near future.  Where can I find the C6745 CSL?  I'm using CCS v3.3.82.13 with the C674x_CSP_RTM.exe patch.  The stock csl_chiphal.h header file does not recognize CHIP_6745.  Should I define CHIP_6713 instead or is there a more recent CSL?

I appreciate the link to the video tutorial.  Previously, I was only able to find the C6472 Outline Course Preview video matching an EDMA3 search.  I was unable to find the associated videos in that specific tutorial.

I now setup a dummy PaRAM entry to handle the last UART TX completion event.  EDMA3 triggers on the UTXEVT event, which occurs when the transmitter FIFO empties or when the UART is taken out of reset using the UTRST bit in PWREMU_MGMT.  This change eliminates the EMR and SER interrupts that occurred after each UART EDMA3 transfer completion.  (I assume that the EDMA3 controller receives a UTXEVT event after the last byte transmits and BCNT reaches zero.  I did not observe this problem with I2C since the I2C controller has knowledge of the total number of bytes to transmit.)

Unfortunately, I still have a problem where I do not always receive a transfer completion interrupt from the UART TX transfer.  I use an atomic variable to prevent additional transfer attempts while one is in progress.  Inspection of the PaRAM suggests that the transfer did complete.  Inspection of EDMA3 SHADOW region 1's IPR suggests a pending interrupt. It appears that after "awhile" the EDMA3 SHADOW region 1 interrupt dispatch function stops running.  What are possible causes that would stop the dispatch function from occurring while the rest of the program continues to run?  I have several other EDMA3 channels running.  Two for I2C, and one for UART RX.  Occasionally, I see an SER event from the UART RX event that clears quickly (I still need to investigate).

Thanks!
-Paul

Paul,

The available CSL is part of the BIOS PSP which is provided through the Update Advisor and your registered software links. I believe that the C674x CSL is register-level CSL and not the functional-level CSL. Drivers are provided as part of the PSP rather than the CSL functions from past processors.

I will try to point out to others at TI the problems you had trying to find the videos for the Online Course. I have had the same problems so I save an email that has the link so I can copy it easily to forum posts like the one to you. It should be easier than that, so hopefully we will make it so in the future.

Paul Miller said:

It appears that after "awhile" the EDMA3 SHADOW region 1 interrupt dispatch function stops running.  What are possible causes that would stop the dispatch function from occurring while the rest of the program continues to run?

There may be a small race condition in the EDMA3 Dispatcher code that allows an occasional IPR bit to go unserviced. When this happens (no UART EDMA3 complete interrupt is missed), does the entire system stop, or do you continue getting other interrupts? My suspicion would be that no more interrupts occur, because if you got another one then the EDMA3 Dispatcher would service the pending IPR bit, much later than expected.

I have attached the file EdmaIntDispatcher_c6472.zip which contains the dispatcher routine that another TIer and I worked out to avoid the IPR race conditions. It was written for the C647x family which does use functional CSL, so it will not be trivial to port to the C674x. But I wanted to at least offer an example. It uses two techniques to avoid the race and is written to minimize config bus access time while in the dispatcher. The race condition is avoided by either re-reading IPR or by pulsing IEVAL on exit. I cannot recall the tradeoffs between the two, but there are comments in the header file to explain the differences. I think the IPR method uses more MIPS when there are not any pending IPR bits, and the IEVAL method increases the latency when there is a pending IPR bit. My recommendation is the IEVAL because its downside should be less common that that of the IPR method.

If you would like to upload the EDMA3 Dispatcher that you are using, I can make comments about how to re-write it to incorporate these changes. Or if you do it yourself, please upload that new code to this thread so other users can find it and use it.

Paul Miller said:

Occasionally, I see an SER event from the UART RX event that clears quickly (I still need to investigate).

Why are you looking for SER bits? SER will get set and cleared as a normal part of the operation of all active channels. I recommend eliminating the SER test and include only an occasional EMR test.

Regards,
RandyP

Hi Randy,

I believe you are correct regarding possible race conditions.  How can I eliminate race conditions from the ISR below?

void HWI_EDMA3SHADOW_dispatch(void)
{
    if ((EDMA3CC_SHADOW[EDMA3SHADOW_ID].IPR & (1U<<IMU_TX_EVENT)) == (1U<<IMU_TX_EVENT)) {
        IMU_TX_Complete();
        EDMA3CC_SHADOW[EDMA3SHADOW_ID].ICR = (1U<<IMU_TX_EVENT);
    }

    // LMX9838
    if ((EDMA3CC_SHADOW[EDMA3SHADOW_ID].IPR & (1U<<LMX9838_TX_EVENT)) == (1U<<LMX9838_TX_EVENT)) {
        HWI_LMX9838_TX_dispatch();
        EDMA3CC_SHADOW[EDMA3SHADOW_ID].ICR = (1U<<LMX9838_TX_EVENT);
    }

    // clear error flags
    if (EDMA3CC->EMR) {
        EMR_count++;
        EDMA3CC->EMCR = 0xFFFFFFFF;
    }
    if (EDMA3CC->CCERR) {
        CCERR_count++;
        EDMA3CC->CCERRCLR = 0xFFFFFFFF;
    }
}

I am also investigating the EDMA3 LLD and PSP libraries for use with the C6745 DSP.  I'm using DSP/BIOS version 5.33.06, EDMA3 LLD version 01.10, and PSP version 01.30.00.05.  Since the C6745 appears as a subset of the C6747 with similar EDMA3 events and interrupts sources, I assume I can use the EDMA3 LLD and PSP libraries for the C6747 without modification.

I have a UART driver working with the PSP and GIO interfaces.  This implementation works, however, I wish to customize the receive channel.  My device streams data at a high rate.  I would like to use EDMA3 to organize the incoming data into a circular buffer and access the memory directly as with my previous implementation.  It appears that for PSP to work reliably, it requires both a GIO input and output channel, otherwise it fails to handle framing errors in the ISR routine and stops servicing interrupts.   When I specify only a output channel, GIO_write() sometimes fails to return.  The UART's IIR register indicates pending interrupts.  Does the GIO output channel service UART interrupts?  Can I use my own ISR for the receive channel?

Thanks!
-Paul

Paul,

Even though my previous reply "said" that I attached my example EDMA3 dispatcher file, apparently I forgot to attach the file. We fixed that and the file is now attached to the earlier reply.

My example is intended to handle any of the IPR bits being set, as long as an ISR function has been hooked in. Your version is a bit more customized, but I expect you will be able to pull out the system accesses from mine to fit into yours. I hope that the #defines and #if/endif code does not make it too hard to read. Any comments will be welcome.

Paul Miller said:

Since the C6745 appears as a subset of the C6747 with similar EDMA3 events and interrupts sources, I assume I can use the EDMA3 LLD and PSP libraries for the C6747 without modification.

Yes, the C6745 is a subset of the C6747, so your plan is sound.

Since your last set of questions is moving more into the BIOS driver world, you may get better answers with a new post into the BIOS forum. We can get your hardware running here and some software issues, but the better experts on BIOS are on the BIOS forum.

Regards,
RandyP