EDMA Interrupt stops working under certain circumstances

Found a solution for at least the second part of my question: Using the DSP functions

CLK_gethtime()

and

CLK_cpuCyclesPerHtime()

worked fine for me.

However, still, I would need some help in finding the reason why the EDMA interrupt stops working after a. Any help is greatly appreciated.

Best regards,

HT

HT,

It appears that this thread was moved from a different forum, although I can't tell which one or by whom.  But at this point, it looks like your issue is not really BIOS related, but rather asking for help on how to debug EDMA transfers.  I have moved this thread to the OMAP-L13x forum in hopes that it will get a faster response there.

Dave

Ti Eval said:

Once finished with the DMA stuff I found another periodic (DSP/BIOS PRD) function call which I used earlier but no longer need. The corresponding timer is setup to define a tick as 1000 microsecs.I changed this to 10 microsecs and under specific circumstances, my DMA processing stops working after a short time: It seems that the DMA loop is still running ( I see the paRAM sets being modified propperly) BUT the transfer complete interrupt service routine seems to be no longer called.

It is unclear why you are using this PRD function if you don't need it, and what is the "specific circumstances". When you say DMA processing stop working, what does this mean, do you stop hearing audio?  Could it be that by reducing the timing for the periodic tick ie. increasing the frequency of the periodic function, your program is not able to hit the audio processing loop or interrupt service route for EDMA completion?

What are you doing in the periodic function?

Regards

Mukul 

Hi, thank you for answering me.

I used the PRD function earlier during development to verify that the DMA transfer works propperly. Once this was ok, I commented out whatever code was there in the periodic function, hence, at the moment, this function is called but does nothing. I also tested to completely remove the function from the DSP/BIOS configuration file. What is always left over, however, is the tick function callback CLK_F_isr routed to interrupt 15 and the CLK manager object and corresponding callback function PRD_F_tick. And that seems to cause the described problem.

"specific circumstances" means that the interrupt always stops working after a very few calls of the DMA complete interrupt service routine if I setup the CLK object for a tick time of 10 microseconds per tick (deviating from the default setup which is 1000). Also, the problem occurs "sometimes" if I use 1000 microseconds if the operating time is only long enough (after 30 or 40 seconds).

"DMA processing stops" means that I can see that the DMA subsystem still works, that is,I see that the two paRAM structs which I use are still processed propperly. The interrupt service routine that indicates that one transfer sequence is complete - after a while - simply is longer called. Also, I can hear that the same buffer is repeatedly looped by the DA converter. It is always the same buffer since the exchange of the buffers in the DMA completion interrupt service routine does no longer happen since the interrupt service routine is no longer called.

I also thought about that the DMA complete interrupt function may not be served since the DSP may be busy due the timer interrupt being called too often. However, I use interrupt number 8 for DMA completion, and the CLK subsystem uses interrupt number 15. Hence, at first the periodic interrupt of the CLK subsystem should fail since the interrupt has lower priority. And also, I should see at least the DMA complete interupt service routine being called once a minute or so, but it is NEVER called after the error condition has been entered.

Hope that the is more clear now..

Best regards,

HT

Hi,

I have solved some other issues but the described one is still open. However, I found out that the interrupts are no longer served if this problem occurs because the DSP loops at a symbol "SYS_EXITFXN, UTL_halt:", so I assume that there has been a segmentation fault which brings me here.

So, the question is: If this type of error happens, can I track where the segmentation fault/exception has occurred? Displaying the callstack does not help since it is empty..

Thank you for any help,

best regards,

HT

It is speculated that some sort of exception may have caused the crash. From TI Bios expert (not me):

"Which version of BIOS and CCS?    They should be able to look in LOG or SYS area of ROV tools (or RTA tools for CCSv3) and see the reason for the exception and registers if this was indeed an exception that caused the call to UTL_halt()."

Can you provide that info?

Regards, Daniel

If you look in the BIOS message log (Tools -> RTA -> Raw Logs) you should see a nicely formatted message that tells you the PC value where the error occurred (i.e. NRP) as well as the kind of exception that occurred (i.e. decodes IERR).