RMAN_Init hangs

Update 

I moved RMAN_init() outside Encode task and it is returning IRES_OK now. Now I am having trouble ipcBarCreate() function which is called inside the clock swi thread and it is getting hung.

We are in a time crunch. Please somebody throw some light on this issue.

Thanks

Hi Anish,

It's good to hear that you've resolved your RMAN_init() failure.  I believe the FC examples typically call RMAN_init() (as well as  RMAN_register()) from main().  The context of a Clock fxn is quite limited, so I'm not surprised to hear that RMAN_init() might hang when called from a Clock fxn.

I don't know about ipcBarCreate(), that sounds like it might be private to the H264 encoder.  I recommend making a new post with ipcBarCreate(), or something related, in the title, since folks who might know about that function won't necessarily even look at a post with just RMAN_init in the title.

Regards,

- Rob

Rob-

Then what's the SYSBIOS solution to processing continuous video?  If Anish can't use a clock task, and he needs to process one frame every N msec, what are the options?

The TI demos run a task that does all frames at once -- not applicable in a continuous, real-time application.

-Jeff

Jeff Brower said:

If Anish can't use a clock task, and he needs to process one frame every N msec, what are the options?

Hi Jeff,

Sorry if I wasn't clear.  My advice about the Clock fxn was just to not call RMAN_init() from there.

While it's true that a Clock fxn's context is more limited than a Task, there are many useful SYS/BIOS calls that can be made from there, but probably limited to things that can never block.

FYI, an alternative to using a Clock fxn is to have a Task that pends on a Semaphore that is posted by a Clock fxn, or perhaps just doing a Task_sleep().

Regards,

- Rob

Rob-

It appears that ipcBarCreate() calls Bar_create() and that hangs.  Is Bar_create() prohibited from a clock task?

In searching for Bar_create on the TI site I can't find an API reference for it.

-Jeff

Jeff,

We're trying to find someone who knows about ipcBarCreate()/Bar_create() who can answer your question.

However, I would strive to not "create" anything from within a Clock fxn.  Perhaps the code that creates the Clock can also "create" or setup everything that is needed by that Clock.  And if the Clock is created statically in a .cfg file, then main() can setup its dependencies.

Regards,

- Rob

I was getting stuck at  Bar_create() .So  I added two lines to the .cfg file following this thread http://e2e.ti.com/support/embedded/tirtos/f/355/t/283364.aspx.

var GateSwi = xdc.useModule('ti.sysbios.gates.GateSwi');
HeapMem.common$.gate = GateSwi.create();

After that changes, the original Encode Task Thread is not producing the encoded output.

Has anyone faced  this issue?

Thanks

Hi Anish,

I have not tried the clock function changes with Encode Task.

But I would like to know the context at which encoder failed to produce output.

Encoder create call is successful?

If successful, process call returned any error or hanging?

Any cache issues can be checked by disabling cache at the function TestApp_EnableCache.

Thanks and regards

Sudheesh

Sudheesh-

Thanks Sudheesh for your fast reply.  When replacing the thread task with a clock task, code inside h264hpvenc_ti_testapp.c hangs on memory_calloc (inside Bar_create), so we made the config file changes Anish outlined above.  But those changes prevent the thread task version from running correctly.

Before going any further we want to ask why using GateSwi causes a problem?  I would think it has no effect on a thread task, which is not using SWI.

-Jeff

Hi Anish and Jeff,

The EncodeTask() function from the H264HP encoder unit test application implements all of the following steps:

system init and setup: including rman init, ipc setup, and etc,

codec create,

codec process: encode all the frames from the input, and

system deinit.

Since the clock function you newly created will be executed periodically, it should contain only the step of codec process (for one frame). The remaining steps need to be executed just once and should be placed outside of the clock function.

Thanks,

Hongmei

Hongmei-

Thanks for your reply.  Yes now we are "re-modeling" the code as you describe.  We're moving one-time code to an H264_init function called from main().   Is that ok, or does BIOS_start() have to be called first?

Once that's done I'm still expecting to face issues with malloc (and possibly other functions required by the encoder) that can't be called from a clock task.

-Jeff

Hi Jeff,

Calling H264_init from main() and before BIOS_start() should be fine. 

Thanks,

Hongmei

Hi Hongmei,

Thanks for your help. I moved all the initialization and codec create code to a different function outside of clock function. Now clock function contains only code for codec process and instance deletion and system deinit.

I am working on moving instance deletion and system deinit. code outside the clock function once the encode process is over. Should I be creating a task thread at the end of clock function to achieve this or is there any other way to execute code once the clock function is over?

Thanks

Anish

Anish Mathew said:

I am working on moving instance deletion and system deinit. code outside the clock function once the encode process is over. Should I be creating a task thread at the end of clock function to achieve this or is there any other way to execute code once the clock function is over?

Hi Anish,

A general paradigm to follow here would be "do not initialize/create/destroy/deinitialize anything in a Clock function".  So no, you shouldn't be creating a Task thread from within a Clock funciton.

I'm not sure why you're using a one-shot Clock for a periodic encoding step, but here's some suggested pseudo-code:
clockSetupTask()    /* this is a Task */
{
    /* setup everything needed by the Clock fxn */
    ipcBarCreate();
    `other stuff needed by clockFxn`;
    clockDoneSem = Semaphore_create(0 /* for Semaphore's count, i.e., unposted */);
    clockHandle = Clock_create(clockFxn, ...);

    Semaphore_pend(clockDoneSem, `forever or some timeout`);

    Clock_delete(clockHandle);
    Semaphore_delete(clockDoneSem);
    `other stuff to cleanup`;
    ipcBarDelete();
}

clockFxn()
{
    `encode`;
    Semaphore_post(clockDoneSem);
}

Regards,

- Rob

Rob-

Thanks.  Your recommended method is what we're working on next.  For the time being, we are exiting from SYSBIOS after the clock function has repeated as needed and performing cleanup in the exit function.

A few reasons we're using clock functions:

  -we need to precisely stagger processing on each core

  -we are running multiple periodic tasks that need to synchronize
   with each other based on data dependency.  Even if no data is
   available, they still need to run and update various things

  -in our experience they are more resource efficient

We've added some SWI configuration code in our config file to allow clock functions to perform malloc().

-Jeff