dynamically creating the biosusb tasks.

I'll ask the BIOS PSP team to look at answering this...

Peter,

Just to add a bit of input...

There doesn't seem to be anything in your description that would indicate why you are seeing this problem -- theoretically, it should work.

The fact that you are creating the tasks dynamically rather than statically adds a temporal element to the application.  If you are creating the task later than when they are actually needed, then this would be a problem.

Another factor is that your memory configuration will be impacted by the fact that you are dynamically creating the task.  Perhaps the stack  being created is inadequate.  If your debugging shows that the task is being created and started before the crash, then you'll need to see if you're blowing the stack during execution.

We're curious on why you found it necessary to move away from the static creation model?  Doing so will potentially impact both memory footprint and CPU loading, plus there is also a penalty in terms of code complexity and debugging (that you are currently experiencing).

Thank you for your response, I agree theoretically it should work, hence the questions.  As to whether I am creating the tasks in time for the program to function, I believe so. I call configureUSB(), then create the tasks, then call dsp_bios_entry(NULL).This mimics the same behavour  have used with static creation of calling configureUSB in main, then exiting main and then the tasks become active, then calling  dsp_bios_entry. I have also been able to call configureUSB in a separate task, after main and then call dsp_bios_entry() immediately afterwards. I may have tried creating the tasks then calling confgureUSB, then calling dsp_bios_entry(), but I seem to recollect that this caused the USB to register with all its identity information set to 0, because the tasks were active prior to configureUSB being called, but that may be a wrong memory.

I don't believe I should be seeing any stack overflow behaviour the tasks are created dynamically, and so should be heap based. In my debugging I am able to see all the tasks being created, but the program resets on calling dsp_bios_entry(NULL), at least in one configuration.

As to why I'm creating this, it is so that I can deliver a library for use in other company projects, and being able to create an all encompassing USB communications object in pure code. I am aware of the slight increase in memory usage that the documentation talks about, but not on CPU loading, unless you mean in creating the object. n terms of debugging, I haven't found it simpler/more difficult using dynamic or static creation, except one works as expected and the other baulks.

Thank you for  your input so far, but yes I would be interested in why I should be experiencing problems dynamically creating the USB tasks.

Peter

Peter

Are you trying to creating the dynamic tasks in application main function or in the another task context.

I suggest call ConfigureUSB in main ( ) , followed by creating the dynamic tasks for BIOSUSB stack, then in the application context call dsp_bios_entry( ). (refer to BIOSUSB example).

Ideally there should not be any problem.

Regards

Ravi B

Ravi,

Sorry for the delay,

Thank you for your reply,as you see I have tried to follow your advice and failed:

I have set my code to initialise the EDMA3 driver (because I am using the USB with EDMA support), then call configureUSB, then in one of my own tasks set to  priority 15, I create all four tasks with a priority 0, then I set the jungo tasks to their expected priority of between 4 and 7 and then I yield the high priority task to allow Jungo's tasks to start up and the program then restarts.

I have also tried it with my task set to a lower priority then raising the Jungo task priority and also creating the Jungo tasks at their expected priority of between 4 and 7, each time when the Jungo task is allowed to run my program restarts.

Regards,

Peter