Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

I am running DSP/BIOS on the DSP and linux on the ARM (MDK_2012-08-10).

The DSP receives data from the McBSP1 via EDMA using the SIO_issue()/SIO_reclaim mechanism from the TI example. After processing the data, it is loaded into a section of DDR memory that is shared with the ARM. This shared area is not cached.

On the ARM side, it periodically copies a chunk of data from the shared memory (also not cached on the ARM side) into a area that is cached (buffer1), then writes it to a buffer (buffer2) in smaller chunks. This last buffer (buffer2) is then written to a SATA drive using fwrite().

Here's the problem: I would like to use larger chunks of data to write to the SATA to be more efficient. However, I find that if buffer2 is 1K or greater the DSP hangs in a SIO_reclaim() call that never returns. This stops the data flow in its tracks. I have checked the McBSP1 and EDMATC1DSP registers on the DSP side and they never change once configured. The mcbspInputTask is blocked pending on a semaphore. The SIO_reclaim has a timeout, but execution never reaches the line following the call. No timeout, no return, so no data flow.

On the ARM side I have isolated the code that creates the hung DSP by commenting sections of code. It's not the fwrite() to the SATA drive. It's the reformatting and copying of data from buffer1 to buffer2. If buffer2 is ~70 bytes, all is well. If buffer2 is 1024 bytes the DSP hangs. If no copying is done between buffer1 and buffer2 (just write junk to SATA), all is well and the DSP never hangs (even if buffer2 is 74K).

I can't think of a reason transferring data from one buffer to another on the ARM would cause the SIO_recalaim() call to hang on the DSP. Any thoughts?

Mary