DSP/BIOS - PRD disturbunce

Hi Dave!

Thanks for the quick response,

I looked at the thread and tried all of the suggestions- but nothing worked.

I increades the system stack size and the task stack size,

I also tried changing all the object's memory to IRAM.

My interrupt rate is low- 16K for the HWI and 100ms for the PRD.

0880.tsk_audio.txt

I attached the TCF file of my project, hope it might help.

Thanks,

Ariel

Dave? Anyone?

I really think the problem is related to memory/stack but I am not sure i have taken the right steps to

solve the problem.

I can see in a different project that when I activate a PRD function directly- things fail,

but when I set the desired function as a task, block it with a semaphore and post a semaphore periodically- things work.

Does someone have an explanation for this?

I tried increasing the system stack size and also the task stack size through the TCF file- with no effect

Is there something more?

Thanks in advance

Ariel

Ariel,

Eric Wilbur here - how are you? I guess not as good as you could be if your system was working.  ;-)

It looks like your project is based on the 4-day BIOS workshop code base. Of course, you've added some stuff as well I see in your TCF file. It was difficult to see exactly what was "current" - maybe cleaning up that script file and re-posting it might help.

In the workshop, if you remember, the PRD caused contention with the audio thread because the PRD ran as a SWI and the processing algo (copy or FIR) ran as a TSK. The dip_monitor (DIP_get) function in Logic PD's BSL takes a gabillion cycles. Even the LED functions take a LONG time in comparison to "normal" real-time events. So, the fact that the dip_monitor isn't working doesn't surprise me. If you create a dummy PRD SWI that simply does a LOG_printf(), you'll find the problem is not, most likely, the PRD (SWI), but the BSL function. Try that - this would narrow the debug to "it's a BSL problem" vs. "it's a PRD problem". Those BSL functions are dog slow and are only used for connectivity and convenience - performance was NOT a careabout.

A couple more things to check or keep in mind:

1. If you are using the straight-away BSL from LogicPD, it is NOT BIOS compatible. Hence the need for the USTimer function I had in main() in the workshop code which I re-wrote to make BIOS compliant. The USTimer delay function from Logic PD stomps on the BIOS timer used for PRD functions - don't use it. Use the one that I wrote for the workshop instead.

2. In the workshop, the PRD function we called was SEM_post and the argument was the SEM. The dipMonitor function ran as a TSK that was LOWER priority than the processing thread. When I looked at your TCF file (from what I could see, I could be wrong), it seemed that you were calling dipMonitor directly from the PRD. That DIP_get BSL function is HUGE in terms of cycles and has some hardware dependencies via I2C that might lock out other HWIs due to a bus hold or something like that. It is dangerous to run that function as a SWI - because it takes forever - longer than forever. ;-)  So, after you determine what is going on in #1 above, try post a SEM from the PRD with the argument as the SEM itself. Then make dipMonitor the lowest priority TSK in the system and see if that helps.

3. Lastly, and this is probably NOT the problem, but worth mentioning - that McASP is very sensitive to underruns - not feeding it properly. If the HWI gets behind in writing to the XMT serializer, the McASP transmit will die. You will cease getting McASP XMT interrupts. Sure, the XMT and RCV are tied together on the C6748 and you'll still get RCV serializer interrupts, but your path thru the XMT side will be dead. I re-wrote the ISR code to handle the XMT side differently than the RCV side - not sure if you have the latest code - there was a bug in the code as of May 2011 that I fixed in June and re-posted. I was responding to BOTH interrupts and reading/writing samples when I should have checked the XRDY/RRDY bits to decipher WHICH serializer caused the interrupt and then only READ or WRITE respectively. This caused a slight noise in the audio. Again, probably not your problem - but worth mentioning.

I hope SOMETHING I mentioned at least takes you down the right path. If not, I'll try to help more...

Cheers,

Eric

Hi Eric,

How are you? Im am doing great, though the system is still crashing...

Thanks for the detailed response! 

My system is indeed based on your 4 day workshop. 

I followed your suggestions and here is what I got:

1. I tried reducing the PRD to nothing (LOG_printf- of course I took out the DIP_get functions). Surprisingly, the 

system is still crashing. The PRD is still active (still getting LOG_printf's) but the McASP is dead. I don't receive any interrupts at all.

If I take out the processing task , (the system is left with a HWI and the dip task)  then everything else is working again.

This is the reason I thought that Dave's direction might be correct-not enough system stack size , but that also didn't work... (though maybe I did something wrong)

2. I also tried posting a semaphore periodically instead of activating the function directly. but there was no difference.

This suggestion made a difference in a different system based on SWI. In this system which is based on tasks it still crashes.

3. Your third comment is interesting, however, even if the XMT side is dead, I should still receive interrupts (as you mention that the XMT and RCV are tied together)

Thanks for all the help!

Ariel

Ariel