RTOS/EK-TM4C1294XL: RTOS example VS Normal example

Hi Ralph
Thank you for the quick reply as usual. :)
I did both tasks you mentioned. I was just playing around USB bulk example ( firmware side and PC side). I want to take advantage of TI  RTOS not by turning ON/OFF led only but using other application such USB, ADC …
As I said previously, I tried the Widget on its own and it did work ( in the example) but when I used the example with RTOS, it compiled successful but nothing happened (blank screen and doesn't response when I touch the screen).

Hi Rab Boud,

rab boud said:

Do you mean find the code of the ISR in the Non-RTOS source code?

rab boud said:

I didn't get this.
On the CCS IDE there is text based RTOS configuration tools to configure the .cfg for the TI RTOS and there is a kind of " manager" (when you open the .cfg file with XGCONF). I only know this 02 tools to allow you to configure the RTOS application such as adding and configuring SWIs, HWIs...

/* ================ Hwi configuration ================ */
var halHwi = xdc.useModule('ti.sysbios.hal.Hwi');
var m3Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
/*
 * Checks for Hwi (system) stack overruns while in the Idle loop.
 *
 * Pick one:
 *  - true (default)
 *      Checks the top word for system stack overflows during the idle loop and
 *      raises an Error if one is detected.
 *  - false
 *      Disabling the runtime check improves runtime performance and yields a
 *      reduced flash footprint.
 */
//halHwi.checkStackFlag = true;
halHwi.checkStackFlag = false;

/*
 * The following options alter the system's behavior when a hardware exception
 * is detected.
 *
 * Pick one:
 *  - Hwi.enableException = true
 *      This option causes the default m3Hwi.excHandlerFunc function to fully
 *      decode an exception and dump the registers to the system console.
 *      This option raises errors in the Error module and displays the
 *      exception in ROV.
 *  - Hwi.enableException = false
 *      This option reduces code footprint by not decoding or printing the
 *      exception to the system console.
 *      It however still raises errors in the Error module and displays the
 *      exception in ROV.
 *  - Hwi.excHandlerFunc = null
 *      This is the most aggressive option for code footprint savings; but it
 *      can difficult to debug exceptions. It reduces flash footprint by
 *      plugging in a default while(1) trap when exception occur. This option
 *      does not raise an error with the Error module.
 */
//m3Hwi.enableException = true;
//m3Hwi.enableException = false;
m3Hwi.excHandlerFunc = null;

/*
 * Enable hardware exception generation when dividing by zero.
 *
 * Pick one:
 *  - 0 (default)
 *      Disables hardware exceptions when dividing by zero
 *  - 1
 *      Enables hardware exceptions when dividing by zero
 */
m3Hwi.nvicCCR.DIV_0_TRP = 0;
//m3Hwi.nvicCCR.DIV_0_TRP = 1;

rab boud said:

I took the same approach by letting the RTOS knowing where is the ISR; I found the ISR code in the non-RTOS example then I used the code above to point toward this ISR.

This is the correct thing to do. However, you must also ensure any code in the non-RTOS example that initializes the ISR in anyway is removed as this will conflict with the Hwi Manager.

Regards,
Derrick

Hi Rab Boud,

The "interrupt number" will correspond to an index in an interrupt table.

Somewhere in the non-RTOS example will be a board support file which places the USB_ISR_Fxn() at a particular index. Additionally, you can refer to the Nested Vectored Interrupt Controller (NVIC) section of the datasheet. Based on the datasheet, I suspect you want interrupt 58 corresponding to USB MAC.

rab boud said:

For example for a USB transmit interrupt or Receive interrupt, can you configure that in the *.cfg fille using text based or manager?

Hello Derrick,

"The "interrupt number" will correspond to an index in an interrupt table.

Somewhere in the non-RTOS example will be a board support file which places the USB_ISR_Fxn() at a particular index. Additionally, you can refer to the Nested Vectored Interrupt Controller (NVIC) section of the datasheet. Based on the datasheet, I suspect you want interrupt 58 corresponding to USB MAC."

Related to my LCD example, I found the NVIC table above.  In this case, the LCD  ISR is called TouchScreenIntHandler and it is attached to hardware interrupt ADC sequence 3 ( or vector number 65).  Is that what you meant? 

If it is, so for RTOS example; do I need just  to replace the " TouchScreenIntHandler" in the NVIC table by IntDefaultHandler (as all the other once) and make *.cfg file point to TouchScreenIntHandler function?

Also why the same code appear in two different files (hw_nvic.h and hw_types.h) . I though this will generate an error such " .. redefined..". Of course here it didn't but I couldn't understand why.

Also the RTOS projects haven't got NVIC table file attached to it. I know I can define my own ISR in the *.cfg file but what about the others one that I didn't need. What is their default state?

Regards,

Hello Rab Boud,

That is correct.

For the RTOS example you need to perform the Hwi_create using the TouchScreenIniHandler as such:

#include <ti/sysbios/hal/Hwi.h>

void someFxn()
{
    Hwi_Params hwiParams;
    Hwi_Handle hwiHandle;

    Hwi_Params_init(&hwiParams);
    hwiParams.priority = LCD_INT_PRIORITY;
    hwiParams.arg = someArg;

    hwiHandle =  Hwi_create(65,
                            TouchScreenIntHandler,
                            &hwiParams,
                            NULL);

    if (hwiHandle == NULL)
    {
        /* An error occured! */
    }
}

void TouchScreenIntHandler(UArg someArg)
{
    /* Pre-existing code stays the same... */
}

Not sure why the same code appears in hw_nvic.h and hw_types.h. Maybe someone from the TM4C can address that in a separate thread.

rab boud said:

Also the RTOS projects haven't got NVIC table file attached to it. I know I can define my own ISR in the *.cfg file but what about the others one that I didn't need. What is their default state?

"Just to be clear, TI-RTOS creates and manages the vector table. Your application cannot provide or manage the vector table directly. You can make modifications to it via the Hwi module."

What I mean is the interrupts that are not used in non-RTOS applications are defined to point to  IntDefaultHandler in the NVIC table  by default. Is it the same case for RTOS templates or just left undefined. I know the user has to set their own ISR in .cfg file .

"We are not familiar with LCD code, so we cannot comment on it"

I gave that  as an example but in general if a function is called continuously which is not an ISR routine, how can you adapt that to work with RTOS application? 

Also if the ISR routine is embedded in  *.lib (library file); how can you make the *.cfg file point to it?

Regards

rab boud said:

What I mean is the interrupts that are not used in non-RTOS applications are defined to point to  IntDefaultHandler in the NVIC table  by default. Is it the same case for RTOS templates or just left undefined. I know the user has to set their own ISR in .cfg file .

rab boud said:

I gave that  as an example but in general if a function is called continuously which is not an ISR routine, how can you adapt that to work with RTOS application?