DSP/BIOS TSK cannot switch task？

Xiangsheng,

What happens when you call TSK_sleep()?  TSK_sleep should force a Task switch.  Also make sure your timer is ticking for TSK_sleep to work properly.

I am not familiar with the RMAN API so I don't know what that is doing but it should not influence a task switch unless its corrupting something.

Judah

Thank you for your replay!

If i don't call the decode code, i can call TSK_sleep() or other SEM_pend() function to blocked my task  and switch task successful.

When i call the decode code and make a breakpoint before call TSK_sleep(), I found that there are a lot of  same message: SEM: post _MEM_mutex (0x8810f524) in the ROV(CCS4.1) LOG_system info. And then i run the TSK_sleep() and halt the task(use the halt button in ccs4,because the task in running and not run back my task), i found the next message in LOG_system: SEM: post _MEM_mutex (0x8810f524); SWI: begin KNL_swi (TSK scheduler) (0x118186f8);TSK: blocked TSK_vehicle (0x83f2406c);TSK: running TSK_idle (0x83f2400c);SWI: end KNL_swi (TSK scheduler) (0x118186f8) state = still ready (The TSK_vehicle is my decode tsk).And i also found my task state in the ROV is "unknown",  the idle task state is "running" . When i halt the task everytime, i found the task run in CSL_intcVectorTable() function (the function in the decode code lib) by use the Disassembly Window. I also found the B3 register address is the "fxnrt" index.  I don't know what's happen in my task.  Because I don't know what happen in the decode lib,maybe there are very offen mutex between dsp,HDVICP,EDMA and so on, so i don't know if the decode lib process is non-blocking process (i don't have the source code of decode lib).  If the process is non-blocking, i want to know how to block the decode process lib.

Are you using Codec Engine with VISA calls from your application to call the h264 decoder's process function?

The call to RMAN_assignResources() should be part of your codec initialization code ('create' phase). This call is used to manage and assign IRES based resources (EDMA channels, HDVICP, ...) to the codec. If the codec needs implements IRES interface, requesting these resources, this function must be called. I have no idea what you are suspecting re: this function affecting your subsequent TSK_sleep calls.

Typically the decoder's process() function should run to completion and should not be affected by your application level task switching - assuming you are running a single codec instance.

Thank you for your replay!

I just use the Codec decode routine in the dm6467_h264dec_1_10_05_03_production. In this routine, the application will call the H264 decoder's process function after call the RMAN_assignResources() to assign some resource.

I am also confused by the task switch problem. If i run the decode routine continually, the program run ok. But if i blocked my decode task with TSK_sleep function or other task switch function (such as SEM_pend) my task looks like collapsed. I just running a single codec instance with the codec decode routine in the dm6467_h264dec_1_10_05_03_production.

I also test my task, use the decoder routine to decode just one frame, and free all the resource in code. But that  also cannot blocked my task.

Now, i am afraid that the codec decoder cannot stop after decode just one frame, but i cannot found the answer in user guide of the dm6467_h264dec_1_10_05_03_production and the internet. Ireally want to know if the do-while loop decode process moudule in dm6467_h264dec_1_10_05_03_production's routine can be suspended?

Thanks.

I also found that  if i use the TSK_sleep(X_Ms) or Sem_pend(X_Ms), my task will be the run to "unknown" state. I means if the task switch have the time thresh, such as 10ms, the task will run in "unknown" state. But if i replace the time with "SYS_FOREVER", my task will be ok (run in the "blocked" state).

And i also found that if i run the decode code, the interrupt arm2dsp has no effection,the HWI  isr will not run. (In my program the am2dsp interrupt will trigger a HWI isr) The decode coder will influence the HWI isr ? 

what's happen? My dm6467 is 990MHz and the clock setting looks like correct. 

Sorry, its not making a lot of sense.  Sometimes "unknown" state is okay but I didn't get what you mean by "But if I replace the time with "SYS_FOREVER""?  What is the "time" that you are replacing?

If the interrupt arm2dsp has no effect, maybe global interrupts are disabled?

I have no knowledge of what decode coder is doing so I can't speak to that code, but if its looking like that code is where the issue is then this post should be moved to the codec forum because people on the BIOS forum won't know much about specific codecs.

Judah

Thank you for your replay.

"But if I replace the time with "SYS_FOREVER"" -- It means that i replace the sentence "TSK_sleep(30)" by TSK_sleep(SYS_FOREVER), the tsk run in the blocked state (the correct state), but if i run the sentence "TSK_sleep(30)", the task run in the "unknown" state.

About the interrupt, before i run the decode coder the the interrupt arm2dsp trigger is ok (the interrupt use the HWI channel 4,select event use 16, the setting is ok), and after run the decode coder the interrupt has no effect, i also run "HWI_enable()"  after run decode coder to enable the global interrupt. The problem confused me. After the TSK_sleep(30), the task run in "unknown" state, but the timeout is 31 and timeremaining also is 30 (but i found the  the timeout is 31 and timeremaining  should be 0,it means that after run the decode coder in my task the timeremaining data don't  change) in the ROV-TSK,  the task will not wake up. 

I will also check the interrupt registers after run the decode coder.

Thanks.

You should never do TSK_sleep(SYS_FOREVER).  If you do SYS_FOREVER, the task is put on a different internal queue than a real timeout.  Again "unknown" can be a valid state.

When you run the decode coder, can you put a breakpoint on the CLK ISR?  The default CLK isr runs on HWI14.  Looks to me like maybe the decoder is either disabling interrupts and not re-enabling it, or maybe its taking up all the CPU time and the CLK doesn't get a chance to run.

Judah

Thanks for your replay!

I would not do TSK_sleep(SYS_FOREVER) in my task, ii just compare the two situation :TSK_sleep(SYS_FOREVER) and TSK_sleep(30). Now, i know the "unknown" state can be a valid state even if the "unknown" state of task is strange.

When i run the decode coder, i don't how to put a breakpoint on the CLK_ISR. The CLK_isr looks like a  built-in function. Yes, I also use the Timer0 (correspond to HWI14). I suspect that the decoder is either disabling interrupt and not-reecabling it ,but i have reenable all the HWI, the problem does not disapper. I found that after run the decode coder in my task, the system-tick in the ROV-KNL-SYSTEM is a fixed number such as 9. And the CLK_isr  function looks like not call after exec the decode coder . I use the HWI dispatch and mask self. This means the decode coder "taking up all the CPU time and the CLK doesn't get a chance to run"?

I'm crazy.

For breakpoints on the interrupt vector for the C6000 family, there's a register called ISTP.  This gets initialized to the reset vector stub and every 32 bytes is the next interrupt vector stub all the way through vector 15.  So you can always put a breakpoint in the vector stub to catch the interrupt.

Mask self will only mask your own interrupt when you are running.  But if you interrupt is taking too long and its higher priority then the CLK  interrupt then, yes its possible that the CLK interrupt never runs.  By the way I believe the function is CLK_F_isr for the CLK interrupt.

What interrupts are you using in the system?

Judah

Thank for your replay.

I just use the Timer0 and ARM2DSP0 interrupts. And the ARM2DSP0 isr is very short.

I also found that if i run the H264decode function，the systick will not add any more and the PRD tick count will not add. That means the function PRD_F_tick() called by PRD_clock of CLK moudle will not be called， and then the KNL_swi also will not be called. As the pic depict.

In the rov result, the LOG_system line 3957 and line 3958 is correct， but then the CLK will add and the PRD will not add. The systick is lost， any DSP/BIOS API use the timeout function will lose effectiveness. What‘s happen to the CLOCK ? 

Thanks.

I'm not sure what you mean regarding Timer0.

Are you saying that you've enable an additional timer interrupt separate from the timer driving the CLK module?

If so, what is the period of the Timer0 interrupt? Could it be that your application is not able to keep up with the interrupt rate?

Also, how have you configured the interrupt for Timer0? Is the Timer0 ISR invoking any BIOS APIs?

If the original problem this thread was opened for (and the other thread you posted this same question in) has been resolved please mark them both answered and start a new thread for this new topic.

Alan

Thank you for your replay.

Timer0 is the sysclock with HWI_INT14. The system have two timer: timer0 and timer1. I just use the timer0. 

The original problem have not resolved.

My global setting info depict as the next pic. The Board clock in my system is 33000kHz.

I don't know what's happen in the PRD clock count  depict  in my last replay poster. After call the h264decode the PRD_F_tick() of the PRD_clock CLK object seem will not be called. So that the task scheduler function KNL_swi will also not be called.

I also found that if i just call the h264decode init function( set the parm and malloc memory), the CLK_F_isr can be called, PRD_F_tick() cannot be called; but after i call the h264decode function H264VDEC_decode() decode one or some frame video, the CLK_F_isr() and PRD_F_tick() will not be called again, and the tsk run to function CSL_intcVectorTable:() in disassembly windows(apparently the tsk  run in error state). I cannot understand that the CLK_F_isr() will not be called,that means no clock in my task.

I also don't understand the sentence "If an external clock is used, it can call PRD_tick to advance the system clock. Another possibility is having an on-device peripheral such as the codec that is triggering an interrupt at regular intervals,call PRD_tick from that interrupt’s HWI." in the doc SPRU423H(page 4-75). I guess the codec take over the system clock, and so the Timer0 is unused. I also don't know what's the meaning of “SEM: post _TSK_mutex ” and “SEM: post _MEM_mutex ”.

Thanks.

It appears that either interrupts are being globally disabled (GIE) or that interrupt 14 is being individually disabled ((IER bit 14) by some thread.

When the system quits working, use the CCS register view to obtain the current value of the IER register. Bit 14 should be set.

Also confirm that the GIE bit is set within the CSR register.

Alan

As a test to see if HWI14 is getting re-used by CSL, can you try using Timer1 as the CLK timer source?

Alan

Thank you for your replays.

You are correct. I found in my project, the csl function re-build the interrupt vector table that created by the BIOS. 

Because the h264decode lib example run in the dsp without the BIOS, and then i add the BIOS to the example. So when i run before the H264decode code, the interrupt vector table is built by the BIOS; and after i run the h264decode code, the interrupt vector table is re-built by the CSL lib function in HDVICP_configure function. Even if the interrupt is enable in IER, the ISTP was changed by CSL, the interrupt isr will not be found correctly.

Then I also have another question: how to rebuilt the interrupt vector table after run in h264decode? I found that if i changed the ISTP after the h264decode with the original address before run the h264decode, the code can run correctly. But i want to found a method run the system correct without change the ISTP after run h264decode, because i will run the h264decode code frequently.   I think to add the timer0's interrupt isr (CLK_F_isr) in the CSL interrupt vector table, but the CSL and the BIOS interrupt vector seem different. Do you have a good idea in this problem? The h264decode seem only have the un-bios example in ti website.

Thanks.

shao

Shao,

I don’t know your specific application requirements… but it seems that since you are using DSP/BIOS, it would be best to port the code that is using CSL for managing interrupts to use DSP/BIOS for the interrupts instead.  Switching ISTP back and forth may work for now, but there are probably some subtle issues and race conditions that could cause problems.  And if you grow the application to add more interrupts, things may get very complex if you assign some interrupts to one table, and some to another, and try to restrict when certain interrupts occur.  

Scott

Thank you for your replay.

I have had a project with DSP/BIOS, and i want to add a h264decode task in the project. But I found that there is only a h264decode example on windows (i don't use the linux system now, because the existed project use the DSP/BIOS system) without DSP/BIOS, in the example there is only one main() function, and will use the CSL api to re-create their interrupt vector table when call the decode process function. That means if you decode one frame, you must re-create the interrupt vector table. I don't iwhether the mechanism is necessary. So i want to resolve this problem, i also try to add the existed project's interrupt use the CSL API when the decode process function call the re-create interrupt vector table, or i want to add the hdvicp interrupt  of h264decode process function to the DSP/BIOS system, But i don't know if my method is feasible?

Thanks.

Shao,

I think it would be best to add the hdvicp interrupt to be serviced by DSP/BIOS, and eliminate the usage of CSL-based interrupts.  If your application is running on DSP/BIOS, interrupts that will ready application threads to run (i.e., those calling SWI_post(), or SEM_post(), etc.) will require certain scheduler protections (that are not provided by CSL) so that the threads don’t run immediately within the interrupt context.  This is described in section 4.2 of the DSP/BIOS user’s guide (http://www.ti.com/lit/ug/spru423i/spru423i.pdf).

So, since the DSP/BIOS interrupt mechanisms are already necessary for a DSP/BIOS application, I think you should port that CSL interrupt configuration to DSP/BIOS…

Scott