LP-AM261: using FreeRTOS DebugP_log API during intialization, prior to tasks create

I wanted to add that the DebugP_log API will function correctly if we’re not using the FreeRTOS build. We can use it after the board and driver initialization.

Hi Vivek,

I retested the empty_am261x-lp_r5fss0-0_freertos_ti-arm-clang example with inserting a DebugP_log after the init functions

int main(void)
{
    /* init SOC specific modules */
    System_init();
    Board_init();

    DebugP_log("After Board_init()!!\r\n");

    /* This task is created at highest priority, it should create more tasks and then delete itself */
    gMainTask = xTaskCreateStatic( freertos_main,   /* Pointer to the function that implements the task. */
                                  "freertos_main", /* Text name for the task.  This is to facilitate debugging only. */
                                  MAIN_TASK_SIZE,  /* Stack depth in units of StackType_t typically uint32_t on 32b CPUs */
                                  NULL,            /* We are not using the task parameter. */
                                  MAIN_TASK_PRI,   /* task priority, 0 is lowest priority, configMAX_PRIORITIES-1 is highest */
                                  gMainTaskStack,  /* pointer to stack base */
                                  &gMainTaskObj ); /* pointer to statically allocated task object memory */
    configASSERT(gMainTask != NULL);
...

The DebugP_log was printing correctly.

After Board_init()!!
All tests have passed!!

Can you test this on your side?

Thanks!

--Gunter

Hi Gunter,

 Yes, it works if I execute only the system init and board init functions:

// code

System_init();

Board_init();

DebugP_log(“\n[main.c] before task creation…\r\n”);

However, it doesn’t work if I execute the following code:

// code

System_init();

Board_init();

Drivers_open();

Board_driversOpen();

DebugP_log(“\n[main.c] before task creation…\r\n”);

Without drivers open, I won’t be able to access peripherals. Could you please let me know what additional steps I need to take?

Regards,

Vivek

Hi Vivek,

is there a reason why you don't want to call Drivers_open() within freertos_main() or empty_main() which are inside of the first task create, as done in the empty example?

Regards,

--Gunter

Hi Gunter,

I’m initializing the platform before starting a task. Therefore, I want to use HwiP before the actual task begins.

Hi Vivek,

the following code works too.

int main(void)
{
    /* init SOC specific modules */
    System_init();
    Board_init();

    DebugP_log("After Board_init()!!\r\n");

    Drivers_open();
    Board_driversOpen();

    Board_driversClose();
    Drivers_close();

    DebugP_log("After Drivers_close()!!\r\n");

    /* This task is created at highest priority, it should create more tasks and then delete itself */
    gMainTask = xTaskCreateStatic( freertos_main,   /* Pointer to the function that implements the task. */
                                  "freertos_main", /* Text name for the task.  This is to facilitate debugging only. */
                                  MAIN_TASK_SIZE,  /* Stack depth in units of StackType_t typically uint32_t on 32b CPUs */
                                  NULL,            /* We are not using the task parameter. */
                                  MAIN_TASK_PRI,   /* task priority, 0 is lowest priority, configMAX_PRIORITIES-1 is highest */
                                  gMainTaskStack,  /* pointer to stack base */
                                  &gMainTaskObj ); /* pointer to statically allocated task object memory */
    configASSERT(gMainTask != NULL);
    ...

[Cortex_R5_0] After Board_init()!!
After Drivers_close()!!

But putting a DebugP_log between the open and close functions causes an assert.

Regards,

--Gunter

Hi Gunter, Vivek, 

Let me check, run some tests and get back with my observations

Regards,
Shaunak

Gunter Schmer said:

But putting a DebugP_log between the open and close functions causes an assert.

The DebugP_log has three ways to output: CCS console, UART or memory dump. You can change the it in the DebugP Log option in example.syscfg. For real time environment, you want to use the memory dump, or UART (if the DebugP_log calling frequency is not too high). Never use the CCS console, because it is very intrusive (disable interrupts and slow). The FreeRTOS assert comes because of the interrupts hindering the task creation for the freertos_main function here and staring scheduler subsequently.

The UART COM Port logs will come up after the Drivers_open() is called. Before that, the DebugP_log API will log in the CCS console (slow and not really recommended).

I'm still figuring out a way to not run into asserts from FreeRTOS taskSwitchContext(). I'll reply back with more findings.

Regards,
Shaunak

I believe in case of NoRTOS vs FreeRTOS DebugP_log usage, there is some config done/handled specially after a FreeRTOS task is created and it expects the log API to be used only after/within the context of the task. This is not the case in NoRTOS

Thank you, Shaunak.

The primary reason for asking this question is that I want to initialize the platform before creating tasks in my firmware. During the platform initialization, I want to access HWIP, which is part of the kernel/dpl, similar to DebugP_log.

Currently, I am doing this inside a temporary thread and then starting another thread. Eventually, I want to move this before starting any thread.

Regards,
Vivek

Hi Vivek,

Yes this is a reasonable and valid usecase, I don't see any issues with doing all the HwIP setup before starting a FreeRTOS task. As long as no RTOS functionality (like DebugP_log, ClockP_sleep, Semaphore handling, RTOS ticks related operations, etc) is used, it shouldn't run into asserts or any issues.

Any reason why the current flow of having a platform setup task which does the initialization and later spawns new tasks for actual application is not desirable?

Regards,
Shaunak