DSP/BIOS TSK module

A separate forum for DSP/BIOS is a good idea. I think a lot of times the DSP/BIOS questions get posted to the forum for the processor family on which is it running, but it could make good sense to have a collection forum for all of those. Many DSP/BIOS issues are unrelated to the processor.

And speaking out of the other side of my mouth, could you please provide some details like which processor and platform you are running on, the versions of CCS and DSP/BIOS, and version of WIndows (they always ask that).

If your TSK was created statically, then it should still show up in the Execution Graph. This will confirm for you that DSP/BIOS did not get mad at you and delete your task without asking - that is not something it would do. The Kernel/Object View should give you insight into what your TSK is waiting for and confirm what its status is.

You seem to have already decided that the problem is in SIO_issue, so that may be a useful place to consider. Also, since the McASP is the active peripheral, you could always look at the frame sync on a scope to see if it is still running, but looking at the McASP RRDY bit could be useful, too, or even the data read register, but reading that tends to mess up the McASP getting data to the right place - then again, you do not care about that since everything has halted.

Does it always take about the same amount of time before it breaks?

What else is going on in the program? And in the task?

How often is SIO_issue called?

You could pepper some LOG_printf() calls in your TSK, like just before and just after the SIO_issue() call. Probably would be a lot of data, but once it locks up you will see that last several which should be good enough to confirm that you are not returning from the SIO_issue call.

You could also create another lower priority task that monitors the McASP RRDY bit and logs how long it is active at a time. If the serial port is no longer getting serviced, then RRDY would stay active for a very long time and this other task might be able to report that.

Of course, if SIO_issue or whatever is locking up is a higher priority task or a SWI, then your lower priority task might never execute. That would tell you something, too.

Randy,

thanks for the reply.  Here is a little more context that you asked for:

Platform: OMAP L-137 EVM. (But only using the C6747 core).

System: CCS 3.3.83.13; BIOS 5.33.03; Windows XP.

You're right these questions are always the first things asked but never seem to matter when the problem is discovered [:P]

The program doesn't do much more than read in samples via McASP1/EDMA3.  I'm using the driver template code from PSP 01.20.00.  There also is a periodic timer that blinks an LED every second.  That continues to execute even when the TSK crashes.  But this is not too enlighteneing since a PRD is higher priority that the TSK.  I tried commenting out all the processing in the TSK after the SIO_reclaim call, but the crash still happens regardless.  The TSK while loop is basically the following:

while (1) {

SIO_reclaim(inStream, rx_ptr, NULL);

[do some processing]

SIO_issue(inStream, rx_ptr, BUFSIZE, NULL);

}

Based on the current serial data stream and EDMA3 frame size, a new buffer should fill ~ 1.04ms.

I checked the input FS and other signals and they all look okay. The bug occurs a varaible amount of time after program execution begins.  Sometimes the TSK loop repeats 100 or less times; on other runs it repeats thousands of times before the bug appears.

I'll try your idea of a lower priority TSK and check the McASP RRDY bit and post the results.  Let me know if you think of other ideas.  I'm new to using the SIO module so not sure what would cause it to suspend indefinitely or how to debug it.

Mike

I am not experienced with SIO, either, but there is a lot of good description text in the DSP/BIOS API Ref Guide spru403. At the start of the SIO module are useful points about how it works and the SIO_issue() function description has some good words, too.

Do you have several buffers queued up before reaching this while(1) loop?

The Kernel Object View may tell you what the SIO module is waiting to happen. And it or the Execution Graph may be able to tell you if you are spending any time in IDLE or if your task+SIO combo is in an infinite spin. Even stopping the processor could help find where you are spending the most time, but this will not help if you are pending for something to happen.

My guess is that some kind of race condition is happening in the handling of your buffers within SIO. You might be able to figure something out by looking at the EDMA3 Param for the channel(s) used for the McASP, but that is getting to be pretty advanced debug and might be trying to guess too far ahead of what we know so far.