• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 663 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

error about VIDENC1_process

zhao yanjie
Intellectual 550 points


1、My development is based on DM6437. My algorithm is complient with XDM , but the programm is always hang when the VIDENC1_process is run. What may be the reason?

2、On the only-DSP platform,how can I set a stack size for my XDM algorithm?

Could you help me?

  • 0
    TI__Genius 17205 points

    1.  Can you step into your algorithm and narrow the hang down?  Maybe it's b/c of some resource (DMA?) or blown stack or...?

    2.  The VIDENC1_process() call (and your algorithm) are called within the context of the calling thread - there's nothing special, it's just a fxn call.  When you create the thread which calls VIDENC1_process(), you can typically specify a stack size (e.g. as an argument to BIOS's TSK_create()).

    This may be an interesting article to review:  http://processors.wiki.ti.com/index.php/Stack_issues

    Chris

  • 0 in reply to Chris Ring
    Intellectual 550 points

    First,Thank you very much.
    I still don't solve the problem.
    1  I had initialized the stack size of  VIDENC1_process_task 256K,but even the stack size is 2M,it still be hang.
    2  I set the return value of getStacksize() as 65536,it is still hang.
    3  Once  function is called, it will be hang,even the called function does nothing.
    4  I found if the address-pointer of inBufs or outBufs is null,it wasn't hang.But abviously the program is wrong.
    What may be the reasons?Could you help me?

  • 0 in reply to zhao yanjie
    TI__Genius 17205 points

    This doesn't feel like a stack issue.  Maybe you're not initializing some field correctly and there's a [invalid] pointer dereference going on.  Are you setting all the .size fields correctly?  Setting .numBufs throughout your buffer descriptors?

    You might get lucky enabling the CE_CHECK feature.

    Just curious, what version of CE are you using?

    Chris

  • 0 in reply to Chris Ring
    Intellectual 550 points

    Thank you very much.

    I will try it and check out my program.

    1 Is it the same that my algorithm  is capsulated  as a *.l64P or *.a64P? My develope platform is DM6437.

    2 When may algorithm is capsulated as a *.l64P ,after it is codec-engined,the size of generated *.a64P is only 5K. I think it is wrong.What may be the reason?

  • 0 in reply to zhao yanjie
    TI__Genius 17205 points

    zhao yanjie said:
    1 Is it the same that my algorithm  is capsulated  as a *.l64P or *.a64P?

    Both extensions are used to indicate a library.  Either are fine, though typically these days .a64P is preferred.

    zhao yanjie said:
    2 When may algorithm is capsulated as a *.l64P ,after it is codec-engined,the size of generated *.a64P is only 5K. I think it is wrong.What may be the reason?

    Not much to go on there - we'll need more details if you want more help.  What are you doing to "Codec Engine-ize" your codec?  Are you running the GenCodecPkg wizard (and if so, which 1 of the 3 use cases are you using)?

    Chris

  • 0 in reply to Chris Ring
    Intellectual 550 points

    Thank  you very much!

     

    Chris Ring said:

     Are you running the GenCodecPkg wizard (and if so, which 1 of the 3 use cases are you using)?

    I didn't use GenCodecPkg ,I used the RTSC Codec Engine Wizards.I think both of the wizards are the same ,are they?

    And I have  worked out it, I finded it was not the codec-engine , It was the FVID_queue that caused the error.

    Thank you very very much!