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.

RTOS/TMS320C5515: Function to call for establishing if DSP/BIOS Kernel is executing or not ?

Part Number: TMS320C5515

Tool/software: TI-RTOS

Hi,

I have a few I2C and SPI peripherals on the system board and these have various read, write, and configuration functions to initialize them.

These functions may be called in main() or they may be called once DSP/BIOS is executing.

I was wondering if there is a particular function to call or a register to poll to obtain status of the kernel, if it's actually executing or not.

I'd like to adapt certain functions so they call TSK_sleep() when the kernel is running, otherwise to use a simple do-while(){} delay loop if being executed from the main().

For this to be possible I'd need to establish if the DSP/BIOS kernel is running or not.

Would appreciate some advice of a way to do this.

Regards,

Michael

  • Hi Michael,

    I suggest you to read about TSK_stat() function which retrieves attribute values and status information about a task but not for the whole kernel. See section 2.3 at:

    Also you can read about TSK_sleep() and TSK_stat() in TMS320 DSP/BIOS User's Guide. Figure 4-9. describes Execution Mode Variations and task states:

    Regards,
    Tsvetolin Shulev

  • Hi,

    Thanks for the quick reply.

    I have gone through some of those app notes but have not found anything pertinent.

    I was more after something like the function TSK_isTSK() which "Checks to see if called in the context of a TSK".

    On page 2.498 of "spru404p TMS320C55x DSP BIOS 5.x Application Programming Interface (API) Reference Guide" it explains further :

    This macro returns TRUE when it is called within the context of a TSK or
    IDL function. It returns FALSE in all other contexts.

    This seemed good at first but then later contradicts itself :

    TSK_isTSK() API returns TRUE when the current thread is neither a HWI
    nor a SWI. Thus, TSK_isTSK() returns TRUE when it is invoked within a
    task thread, main(), or a task switch hook.

    I wasn't aware that main() is considered a task per se ... given that to my knowledge DPS/BIOS begins execution once it exists main() ...

    So unfortunately this cannot be then used to determine if a function is called from main() or from a running DSP/BIOS task as far as I can see (unless the explenation in the user guide is not 100% right).

    I've looked at other means including TSK_stat() which does not seem very useful for my context, and TSK_sleep() which cannot be run from main() or IDL function anyway ...

    If anything else (but would need to confirm this) is TSK_self() which apparently returns a handle to the currently executing task, but am not sure what it would return if called from main() ?!? Perhaps a default "handle" to main() or operhaps NULL pointer ?!? The later would be more useful as this could validate my test for main() or NOT main() ...

    Regards,

    Michael

  • Hi,

    So after further testing it would appear that TSK_isTSK() = FALSE called inside main(), but returns TRUE when called inside a running task.

    So it seems the explanation in the spru404p TMS320C55x DSP BIOS 5.x Application Programming Interface (API) Reference Guide is not entirely correct (perhaps I have an older version of it ...)

    Thanks, I think I'll use this way as its easy enough and little overhead.

    Regards, Michael

  • Michael,

    As I'm reading the last TMS320C55x DSP BIOS 5.x Application Programming Interface (API) Reference Guide version spru404q.pdf

    ... TSK_isTSK() returns TRUE when it is invoked within a task thread, main(), or a task switch hook.

    I suspect you are using some old DSP BIOS release.

    Regards,
    Tsvetolin Shulev

  • Hi Tsvetolin,

    Yes its document spru404p from 2009, but the DSP/BIOS we're using is from 2012, I have not checked if in the mean-time the TSK_isTSK() function is mentioned in the bug fix, but from what I can test on my actual application code it is clear that this function does not return TRUE when called from within main(), but from a BIOS task it does.

    So this works out ok for what I'm trying to do, and also seems logical, as main() is not really a task in the normal sense of a BIOS task created for BIOS use ...

    Anyways, thanks for pointing out some of the ways that could be used to do this etc..

    Regards,

    Mike