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.

RTOS/66AK2L06: EDMA sleeps for 30 msec before it starts to react on events

Part Number: 66AK2L06
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hello,

I am using a custom K2L board for transferring 16-bit data from a CPLD through EMIF-16 to DDR3 memory using EDMA3, My problem is that the either the EDMA or the DMA completion interrupt needs some "waking up" until it begins working at full speed.

Everything seems good except for the EDMA sleeps 30 msec in the beginning of the transfers. See the oscilloscope figure below:

The yellow signal shows the events (GPIO 10) from the CPLD to the C66 DSP CPU.

The blue signal (GPIO 9) shows when the DMA completion interrupt is executed.

The purple signal is EMIF read signal.

The green signal is used for activating the CPLD for doing its job which in turn results the yellow signal out of the CPLD.

The figure shows that the CPLD wakes up immediately when the C66 DSP CPU enables the green signal, AND the EDMA makes one read from the EMIF-16. Then it stops working for 30 msec.. Why??? After waking up it does not sleep any more. It can continue working just fine for hours.

Before enabling the green signal the EDMA and its interrupts have been configured and they are not modified after that any more. There is nothing special to happen after enabling the green signal, and the same transfer should continue forever until the green signal is finally disabled by the CPU.

DMA PaRAMs

OPT: 0x80112004

SRC: 0x34000080

AB-CNT: 0x000C0002

DST: 0xA0000180

BIDX:  0x00200040

LINK-RELOAD: 0xFFFF0000

CIDX: 0x00020000

C-CNT: 0x00000010

The DMA completion fires an interrupt which updates the destination address and re-enables the transfer. Each event makes 12 16-bit data transfers and this is repeated 16 times per each green signal pulse. This is not visible (pulses are too close to each other on the screen) in the oscilloscope figure above, but I have verified by looking more closely that this works alright.

I have tried to adjust the HWI interrupt priorities and SYS/BIOS task priorities, but they don't help. There are no other interrupts active which could preempt the EDMA completion ISR. I have also tried removing the EDMA event missed interrupt and the CC error interrupt. No effect.

I have tried with giving the events in different frequencies: 100Hz, 300Hz, 1kHz, 10kHz and 40 kHz. The sleep time is always the same: 30 msec.

I set up the tasks and interrupts like this in the code:

Main task which makes all the settings for the EDMA (uses EDMA3 LLD, driver from TI), GPIO, CPLD and the EDMA3 interrupts (completion, event missed, cc error).

stackSize = 0x2000;
priority = 0; // originally 5

Idle loop which runs all the non time critical functions. Currently it is empty doing nothing. Originally it was included in the main task as a never ending while-loop.
Idle.idleFxns[0] = "&mainTask";

The EDMA completion interrupt is an HWI task having automatically the highest priority level, right? I setup the interrupt like this:

    CpIntc_dispatchPlug(40, isr_handler, 0, TRUE);
    CpIntc_mapSysIntToHostInt(0, 40, 68);
    CpIntc_enableHostInt(0, 68);
    EventCombiner_dispatchPlug(26, (ti_sysbios_family_c64p_EventCombiner_FuncPtr)CpIntc_dispatch, 68, TRUE);
    EventCombiner_enableEvent(26);

40 = CIC0 EDMACC_0_TC_2_INT, the EDMA event  18 (GPIO 10) is assigned to this  in the "ccXferCompInt" array included in the EDMA3 LLD package.

26 = C66 CorePac primary interrupt CIC_OUT68_PLUS_10_MUL_N

The "isr_handler" function (in pseudo language):

isr_handler(const EDMA3_RM_Obj *rmObj)
{
  SET GPIO 9 to "1" this is visible in the oscilloscope (blue signal)
    while (IPR & (1 << 18)) {
           ICR = (1 << 18);
    }
    EESR = (1 << 18);
    UPDATE DMA DESTINATION
    PREPARE EDMA FOR NEXT EVENTS

  SET GPIO 9 to "0" this is visible in the oscilloscope (blue signal)
}

Versions of the used tools:

Compiler: TI v7.4.16

CCS: v6.1.1

XDCtools: 3.30.5.60

SYS/BIOS: 6.45.1.29 [6.42.2.29]      <--  does this mean the project was originally built with a newer version, but this PC has only 6.42.2.29 installed on it? Can this have some effects like this?

IPC: 3.35.01.07

PDK: 3.01.03.06

EDMA3 LLD: 02.11.13.17

Is this a bug in the configuration I have made, or is this a bug in the SYS/BIOS or in the EDMA controller itself?

Best regards,

Ari

  • I've moved your thread to the device forum.

    Todd
  • Hi,

    Is anyone investigating this issue? We just simply cant find any solution for this...
  • Why is this question totally ignored????? Please respond!
  • Hi,

    Sorry, I've missed this.. We'r looking into this. Feedback will be posted here.

    Best Regards,
    Yordan
  • Ari, I got this posting, HI

    The first question that I would ask myself is what is the cause of the delay. I suspect that it is the communication between the external device and the EMIF but 30 milliseconds (is that what you mean by msec?) is just too much, so here is what I suggest:

    Try to drive the EDMA from internal interrupt - that is, for example connect GPIO to be the EDMA triggering and verify that there is almost no delay between the GPIO and the start of the EDMA (You may have to use two GPIOs).

    If indeed the problem is with the interface, I need to know more about the CPLD, and even if because of some reason this takes too much, we can think about work around.

    And I suggest that you have a look at www.ti.com/.../sprabk5b.pdf - it gives information about other interfaces (Not EMIF) but you can see what type of values to expect

    Best Regards

    Ran
  • Hello Ran,

    We are working together with Ari on this subject so allow me to clarify a few things.

    The sleep issue is not coming from the CPLD. This same version of CPLD has been in use for 4 years on a DaVinci processor and it has been proven to be fully functional.

    The principle is that we have one 'CLK_IN' signal coming in from an external source (frequency range from 0Hz and up to 40kHz). This 'CLK_IN' input is wired to GPIO 0. Also, this 'CLK_IN' is configured as an interrupt source. In the ISR of 'CLK_IN', the CPLD is given a 'START' which causes the CPLD to start the AD conversion cycles and outputting 16 pieces of 'INT' pulses to the GPIO 10. GPIO 10 is then configured to launch EDMA3 transfer of 12 data words from EMIFA (so with one 'INT', DMA reads 12 words from CPLD). This cycle is then repeated then 16 times and CPLD starts waiting for the next 'START'.

    Today we tested again with several cards and found out that the sleep is sometimes far more than 30msec.
    The problem is in the ISR of CLK_IN. In the startup after configuring everything the cycle starts just correctly – ISR of CLK_IN is served just fine and data is read by DMA. No problem in here. But, after couple of successful cycles the ISR is no longer served at all and processor goes to sleep for 30milliseconds. During this time, processor totally ignoring all CLK_IN pulses coming into the GPIO 0. Then after the sleep of 30ms, it wakes up again and sometimes it continues correctly forever without any problems. Today we discovered that the processor may have several 30ms sleeps, meaning that after the sleep it gets couple of ISRs served but again goes to sleep for 30ms. This sleep 30ms– couple of OK ISRs – sleep 30ms – of OK ISRs can continue for a long time, longest time we recorded was 180ms before the operation normalized.

    It is quite obvious that the problem is in the ISR of GPIO 0. After kicking this cycle alive, there are long periods until the processor starts noticing GPIO 0 pulses. We are 110% certain that the pulses are going to the DSP since we are always monitoring this signal with an oscilloscope.
    We suspect that the RTOS is the main cause for our problems. See Ari's 1st mail for sw version used in the DSP.

    With kind regards,

    Zeb
  • Anyone????

    This system is now like an old car, leaving the traffic lights it stutters but eventually after getting enough revs, pulls like a train. I need new plugs and ignition timing adjusted for this processor :-)

    Please, give us some useful help.
  • We did more tests and tried another GPIO input (0 and 11) without any effect, problem is the same. Also tried interrupt vector IDs 4,5,6,7, 15 - still the same sleep of 30ms. Varied interrupt priorities, same 30 msec sleep. Sometimes the delay is a multiple of 30ms.

    Removed the SYS/BIOS and did test by using CSL functions - results are exactly same. SYS/BIOS was not started in this case.

    No matter what we try, the 30ms sleep is always there each time we restart to collect data.

    Please, have someone to look into this issue.

  • Is there a reason why nobody replies to this thread? The GPIO interrupts are really not working initially after startup in the DSP - delay can be 30ms or a multiple of this before they are getting served normally.

    It is disappointing to see how you are ignoring the support requests. I will try to find some other way of getting help, this support channel is not working.
  • Zeb

    I am puzzled by the posting and since I do not have your system I cannot repeat the experiment.  So I forward the posting to our system team and see what they think.

    Personally if I can think of something that can cause 30 millisecond delay (and eventually go through) I would think about external player like the CCS itself. It is known that the response time of the CCS with hardware is very long, especially for printf.  But I do not think that you have printf in your code  (I hope you do, it will resolve the issue) or a breakpoint (this is why I never trust the first time there is a measurement of time in a loop that starts from a breakpoint - it takes CCS to deliver the message very long time)

    So please wait a little more.    We are looking to find the right person to answer

    Best Regards

    Ran

  • Ran,

    Thank you for your reply! We had a quick check to see if we have any printfs - and there was.... We did a very quick test and it looked totally different without any delay. I have to admit that we feel "a little" stupid in this end - making a big fuzz over a stupid own mistake. Tomorrow we will test more carefully and report the results here. Anyway the printfs were totally somewhere else than in the executing part of the code.

    So initially this is now looking good but we will report back tomorrow, just to confirm that printfs were the problem.
  • I am happy (and stay happy unless you still have the problem after the testing tomorrow)

    Ran