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.

SYSbios Hwi Configuration Error

Other Parts Discussed in Thread: SYSBIOS, CCSTUDIO

Hello Friends

i am porting starterware rasterDisplay.c to SYSbios, i am using bios-6.34.2.18 and my target platform  is Beaglebone-AM3359. I found the code unable trigger interrupt. And later i followed TI video Tutorial and tried to configure Hwi from CCSv5  app.cfg but after building the project i am getting below error.

 unresolved symbol LCDIsr, first referenced in C:\WorkspaceCCSv5.3\Interrupt_raster\Debug\configPkg\package\cfg\app_pea8fnv.oea8fnv

LCDIsr is my service routine.

Can any one help me in configuring Hwi for Raster controller in SYSbios. And i am really confused with the above error..am looking for a clue.


Regards


  • Hi Satyaprakash,

    It looks like you are getting a linker error and not a configuration error. In case your app has multiple C files, one possible cause could be that the C file that contains the LCDIsr definition is not getting linked. Can you check the linker options and ensure that the object file containing LCDIsr definition is getting linked ? Another thing you want to check is that LCDIsr matches the ISR function name (basically check for any typos).

    Can you also share the xs code you are using to create the ISR in your app.cfg ?

    Best,

    Ashish

  • Hi Ashish

    Thanks for your replay...

    Yes i resolved above posted error, after removing static from the function type.

    But still my code is unable to trigger interrupt...i am little confused.

    I have added BIOS_start() at the end of the main followed by respective header files. But when i am adding Breakpoint on LCDIsr ,i found control is not reaching that point. Then i added Breakpoint over BIOS_start()..and when i stepped into it ..i found some messages...Like No source available /../../BIOS.c and furher debugging took me to app_pea8fnv.c and here i got the same type message No source available ../../../System.c ,  ../../Gate.c,  ../../GateHwi.c  and end-up with CPU hung....

    Is that i am configuring correct things in app.cfg ?,, There are two Hwi configuration such as 1 .Portable Hwi 2. Device specific Hwi. Which one i have to configure..?

    Below i am posting the Generated scripts..is that you have asked me to post ?

     

    System.SupportProxy = SysMin;

    Mmu.defaultAttrs.shareable = true;
    BIOS.rtsGateType = BIOS.GateMutex;
    var hwi0Params = new Hwi.Params();
    hwi0Params.instance.name = "hwi0";
    hwi0Params.priority = 0;
    Program.global.hwi0 = Hwi.create(36, "&LCDIsr", hwi0Params);


    Regards

  • Hi Satyaprakash,

    The no source available message means CCS does not know where to find the source files for opening in the editor window. You can checkout slides 33, 34 and 35 in this CCS ppt to learn how to fix this:

    http://downloads.ti.com/dsps/dsps_public_sw/sdo_ccstudio/presentations/CCSv5_Tips_&_Tricks.pdf

    Satyaprakash Mishra said:

    Is that i am configuring correct things in app.cfg ?,, There are two Hwi configuration such as 1 .Portable Hwi 2. Device specific Hwi. Which one i have to configure..?

    It is okay to use either Hwi modules. The Portable Hwi module is a better choice if you are developing library code as this module is common to all BIOS targets. The device specific Hwi module allows you to exercise some device specific features like selecting interrupt Type (IRQ/FIQ) on a ARM A8.

    The Hwi static create looks ok. Are you sure the LCD is generating an interrupt ?

    Best,

    Ashish

  • Ashish

    At the end of each  frame transfer, an interrupt is set to trigger. Yes i am able to visualize picture on LCD, but  that is the result of one time transfer. But it is necessary to have an interrupt  repeatedly ..so that cpu will mobilize the frame transfer process again and again ..But  BIOS_start() which i called at the end of the main causing  CPU  hung..So there is no time for CPU to reach  LCDIsr. Earlier when i was not calling BIOS_start() & not configured app.cfg ,it was same response at end of main.

    "Thanks to You"                                                                                                                                                                                                                                                                                       Yes after following ur given link ,,"No source available" message resolved and control is reaching deep inside BIOS. But again CPU is getting hung at some point.

    I am just sharing few details.... When control hits BIOS_start() ,Under BIOS.c below  red colored functions under  "ti_sysbios_BIOS_startFunc__I()"  are being called and executed. 

    Void ti_sysbios_BIOS_startFunc__I()
    {
    xdc_runtime_System_atexit((xdc_runtime_System_AtexitHandler)ti_sysbios_BIOS_exitFunc__I);
    ti_sysbios_hal_Hwi_startup();
    ti_sysbios_hal_Timer_startup();
    ti_sysbios_knl_Swi_startup();
    ti_sysbios_knl_Task_startup();
    }

    1>Here among red colored functions why "xdc_runtime_System_atexit((xdc_runtime_System_AtexitHandler)ti_sysbios_BIOS_exitFunc__I);" is called , is my doubt .?  

    2>"ti_sysbios_hal_Hwi_startup();" is being called and i have configured  Portable-Hwi in app.cfg  and implemented code to set Hwi related registers.So this is expected.    

    3>Regarding calling of "ti_sysbios_hal_Timer_startup();", i have not  implemented  Timer specific code in my " .c " file. Is that necessary to include Timer implementation in my source file and set it in app.cfg  ? There are two types of timer in app.cfg (Gp & dm) which will be suitable?  

    4>And regarding "ti_sysbios_hal_Timer_startup();" & "ti_sysbios_knl_Task_startup();", none of these two has configured in app.cfg . so is that creating any issue? 

    And control is executing at all these functions but when it is coming to  "ti_sysbios_knl_Task_startup();" it is raising an Error  in Task.c. And further debugging making CPU hung.

    I am really confused...And Need some Help.


    Regards

    Satyaprakash


  • Hi Satyaprakash,

    Satyaprakash Mishra said:

    1>Here among red colored functions why "xdc_runtime_System_atexit((xdc_runtime_System_AtexitHandler)ti_sysbios_BIOS_exitFunc__I);" is called , is my doubt .?  

    xdc_runtime_System_atexit() is called to register BIOS_exitFunc() as an exit function so it can be called when the app exits. BIOS_exitFunc() does some necessary cleanup before app exit.

    Satyaprakash Mishra said:

    3>Regarding calling of "ti_sysbios_hal_Timer_startup();", i have not  implemented  Timer specific code in my " .c " file. Is that necessary to include Timer implementation in my source file and set it in app.cfg  ? There are two types of timer in app.cfg (Gp & dm) which will be suitable?  

    Your application probably has the clock enabled. The clock module internally uses the hal/Timer to get the OS tick.

    Satyaprakash Mishra said:

    4>And regarding "ti_sysbios_hal_Timer_startup();" & "ti_sysbios_knl_Task_startup();", none of these two has configured in app.cfg . so is that creating any issue? 

    Are you building a Hwi only app (no tasks) ? If yes, then BIOS still creates an idle task which causes the Task module to get pulled in. If you are not planning to use tasks, you can disable tasking by adding the following code to your *.cfg file:

    var BIOS = xdc.useModule('ti.sysbios.BIOS');

    var Hwi = xdc.useModule('ti.sysbios.hal.Hwi');

    BIOS.taskEnabled = false;

    Hwi.dispatcherTaskSupport = false;

    In case you are using XGCONF, there should be a checkbox in the GUI to do this.This will help improve the performance a little.

    Satyaprakash Mishra said:

    And control is executing at all these functions but when it is coming to  "ti_sysbios_knl_Task_startup();" it is raising an Error  in Task.c. And further debugging making CPU hung.

    Can you share the error log that you are getting ?

    Best,

    Ashish

  • Ashish

    I mentioned about Error, But i am not getting any error logs on my console, rather CPU is executing an Error condition under "Task.c". Here below i am giving the function and the Error condition which is executing is marked in red color.

    ******************************************************************************************************** 

    Void Task_checkStacks(Task_Handle oldTask, Task_Handle newTask)
      {
            UInt oldTaskStack;      /* used to obtain current (oldTask) stack address */

    /*
    * oldTask is NULL for the very first stack switch, skip it
    */

    if (oldTask == NULL) {
    return;
    }

    /* check top of stacks for 0xbe */
    if (!Task_SupportProxy_checkStack(oldTask->stack, oldTask->stackSize)) {
    Error_raise(NULL, Task_E_stackOverflow, oldTask, 0);
    }

    if (!Task_SupportProxy_checkStack(newTask->stack, newTask->stackSize)) {
    Error_raise(NULL, Task_E_stackOverflow, newTask, 0);
    }

    /* check sp's for being in bounds */
    if (((UArg)&oldTaskStack < (UArg)oldTask->stack) ||
    ((UArg)&oldTaskStack > (UArg)(oldTask->stack+oldTask->stackSize))) {
    Error_raise(NULL, Task_E_spOutOfBounds, oldTask, oldTask->context);
    }

    if ((newTask->context < (Ptr)newTask->stack) ||
    (newTask->context > (Ptr)(newTask->stack+newTask->stackSize))) {
    Error_raise(NULL, Task_E_spOutOfBounds, newTask, newTask->context);
    }
    }

    After executing above red colored Error condition CPU is moving to Load.c..and here it is getting hung.

    *******************************************************************************

    And as u asked, Yes i am building a Hwi only application. And when i added ur posted scripts in app.cfg, i got below error and warnings.

    Error:

    BIOS.taskEnabled must be set to 'true' when BIOS.libType == BIOS.LibType_Instrumented.  Set 'BIOS.libType = BIOS.LibType_Custom' to build a custom library or update your configuration.

    ti.sysbios.BIOS taskEnabled: BIOS.taskEnabled must be set to 'true' when BIOS.libType == BIOS.LibType_Instrumented.  Set 'BIOS.libType = BIOS.LibType_Custom' to build a custom library or update your configuration.

    Warning:

    Load has task monitoring enabled, but BIOS has task disabled.

    ti.sysbios.utils.Load taskEnabled: Load has task monitoring enabled, but BIOS has task disabled.

    And even i tried the same thing from GUI..and i got the same above error..as if sysbios is forcing me to make Task & Swi enable.

    ************************************************************************

    And as per ur previous replay, why "BIOS_start()" is calling "xdc_runtime_System_atexit()" , in beginning...is it expected ?? 

    Presently am just doing a hit and trial in selecting and deselecting diff configuration...if any clue u have i will be really thank full to you...

    Regards

    Satyaprakash

  • Satyaprakash Mishra said:

    if ((newTask->context < (Ptr)newTask->stack) ||

    (newTask->context > (Ptr)(newTask->stack+newTask->stackSize))) {
    Error_raise(NULL, Task_E_spOutOfBounds, newTask, newTask->context);
    }
    }

    After executing above red colored Error condition CPU is moving to Load.c..and here it is getting hung.

    This error indicates a stack overflow. Can you open ROV->Task view Detailed tab and share the screenshot.

    Satyaprakash Mishra said:

    And as u asked, Yes i am building a Hwi only application. And when i added ur posted scripts in app.cfg, i got below error and warnings.

    Error:

    BIOS.taskEnabled must be set to 'true' when BIOS.libType == BIOS.LibType_Instrumented.  Set 'BIOS.libType = BIOS.LibType_Custom' to build a custom library or update your configuration.

    ti.sysbios.BIOS taskEnabled: BIOS.taskEnabled must be set to 'true' when BIOS.libType == BIOS.LibType_Instrumented.  Set 'BIOS.libType = BIOS.LibType_Custom' to build a custom library or update your configuration.

    Warning:

    Load has task monitoring enabled, but BIOS has task disabled.

    ti.sysbios.utils.Load taskEnabled: Load has task monitoring enabled, but BIOS has task disabled.

    And even i tried the same thing from GUI..and i got the same above error..as if sysbios is forcing me to make Task & Swi enable.

    Looks like you are using the Load module for monitoring the CPU load. The Load module is configured to monitor task load by default. To fix the build error just set Load.taskEnabled = false in your *.cfg script. If you are using XGCONF, there is a checkbox for monitoring task threads that you need to uncheck.

    Satyaprakash Mishra said:

    And as per ur previous replay, why "BIOS_start()" is calling "xdc_runtime_System_atexit()" , in beginning...is it expected ?? 

    Presently am just doing a hit and trial in selecting and deselecting diff configuration...if any clue u have i will be really thank full to you...

    Have you gone through the SYS/BIOS user guide ? You can find it in your BIOS installation's bios_6_xx_xx_xx\docs folder.

    Best,

    Ashish

  • Hi Ashish

    Here is my ROV->Task :Details screen shot.

    And as u said ,i might be using Load module for CPU monitoring, and i found it is unchecked. So when i am adding ur given scripts to disable Task and SWi, i am getting Error as i mentioned in earlier posts. So here i made Task and Swi enable to avoid runtime configuration Error. But i have not included Swi and Task particular field. For better clarification, here am giving the system overview screen shot below...

     

    And as u said..i hv gone through some portion of Bios_User_Guide.pdf  and found BIOS_start() should follow an user supplied startup function, i dont know how to do that..and apart from that, i tried to build some of example project Such as: uartecho and i found here also CPU is following the same flow as before & executing same stack overflow error condition..and what i am guessing the default 4096byte Hwi/Swi stack memory is not sufficient..is that i have to increase my stack memory ?? And will that be the solution ?? 

      Regards

  • Hi Satyaprakash,

    The task stack peak is well within limits. It does not look like the task stack overflowed. You can maybe put a breakpoint at the if statement and determine what are the values of newTask->context, newTask->stack and newTask->stackSize. The newTask->stack and newTask->stackSize values should match the stack base and stack size from the ROV view.

    Satyaprakash Mishra said:

    if ((newTask->context < (Ptr)newTask->stack) ||

    (newTask->context > (Ptr)(newTask->stack+newTask->stackSize))) {
    Error_raise(NULL, Task_E_spOutOfBounds, newTask, newTask->context);
    }
    }

    Satyaprakash Mishra said:

    i tried to build some of example project Such as: uartecho and i found here also CPU is following the same flow as before & executing same stack overflow error condition..and what i am guessing the default 4096byte Hwi/Swi stack memory is not sufficient..is that i have to increase my stack memory ?? And will that be the solution ??

    You can confirm if the Hwi stack is overflowing by looking at the the ROV->Hwi->Module view. The stack peak section will be highlighted red if an overflow is detected. If the interrupts are getting nested several levels deep, then it may be possible that the Hwi stack overflowed but I doubt that is happening as you are saying your interrupt handler is not getting called at all.

    Best,

    Ashish

  • Hi Ashish

    In ROV->BIOS i found some exception, can u tell me why this exception is coming...below is the error message taken from ROV and the snap shot.

    Caught exception in view init code: "C:/ti/xdctools_3_24_05_48/packages/xdc/rov/StructureDecoder.xs", line 544: java.lang.Exception: Target memory read failed at address: 0x0, length: 4This read is at an INVALID address according to the application's section map. The application is likely either uninitialized or corrupt. 

    And one more question, do i have to dynamically create Hwi in my main() function?. At present, i hv just implemented code, how a firmware display driver works and at the end of the main function i am calling BIOS_start(), and based on this am configuring Hwi in app.cfg statically. Is that the correct way to deal with Hwi in sysbios?


    Regards

    Satyaprakash

  • Hi Satyaprakash,

    The current thread type is missing in the ROV->Bios view. Maybe it got corrupted and that is causing the error. Can you put ti_sysbios_BIOS_Module__state__V in the expressions window and see what value shows up for threadType field ? Another thing you can try is hover the mouse over the red highlighted address in ROV. That usually shows an error message.

    Did you check the Hwi module view ?

    It is okay to either create a Hwi statically or dynamically. It should not make any difference.

    Best,

    Ashish

  • Hi Ashish

    As u said i put "ti_sysbios_BIOS_Module__state__V" in expression window but there is no difference  observed in BIOS->CurrentThreadType, it is still blank. Rather i got the  address values in same expression window and it is the similar address as BIOS address. And yes i got exactly the same error when i moved my pointer on to the RED colored zone as i posted in my last post.

    And in answer to ur question, yes under ROV->Hwi i found there is two Interrupt 1.>LCDIsr & 2.>ti_sysbios_timers_dmtimer_Timer_stub__E.

    And as i mentioned earlier, i removed static Hwi configuration from app.cfg and did dynamic Hwi creation in my main function and i observed my ISR (LCDIsr) is being called from BIOS_start() , and when i stepped into LCDIsr it executed perfectly till it ends and returned to BIOS_start() and repeated again and again and That made me happy despite of ROV->BIOS error. And here is the snap shot of ROV->Hwi after Dynamic configuration. Just let me know is it correct ?

    After this, some test cases made me confused...

    1>.when i am not setting breakpoint on BIOS_start() and directly going with single breakpoint on LCDIsr,control is not reaching there.

    2>when am setting breakpoint on both BIOS_start() & LCDIsr control is reaching LCDIsr followed by BIOS_start(), but when further in same debugging session am removing breakpoint from BIOS_start() and the control is at LCDIsr and am not stepping in rather am directly hitting Resume, i found controll is not coming back to LCDIsr...so is that expected ??I expect control should come back to  LCDIsr again and again if a breakpoint is there on it irrespective of stepping into it or not.

    I assume this kind of behavior is due to the ROV->BIOS error...is that so?

    Regards

    Satyaprakash

  • Hi Satyaprakash,

    Can you copy the address show in ROV->BIOS view (red highlighted text) to the memory browser and share the memory contents ? The 6th word is the current threadType. I want to know what value is it set to and why is CCS not able to read the threadType when you lookup the BIOS module state in expressions window. I feel that it might be set to an invalid value causing the ROV view error.

    Generally speaking, if you set a breakpoint at the beginning of your Hwi function, the breakpoint will be hit each time the interrupt is triggered. It seems odd that you need to set a breakpoint at BIOS_start() in order for the breakpoint in your Hwi function to get hit. This may point at some sort of race condition that exists.

    Since I dont completely understand the cause for the ROV error, I will not conclude just yet that it is causing the weird breakpoint behavior you are seeing.

    Best,

    Ashish

  • Hi Ashish

    As u said,  below am sharing the screen shot of my CCS "Memory Browser"...

    And one more thing..in ROV->Hwi i found multiple ISR, one is LCDIsr which is there in my project and another is ti_sysbios_timers_dmtimer_Timer_stub__E. SYSbios might be using default dm-timer in my application. But i found  in ROV->Hwi->Detailed, the priority of Both interrupt is same. And "enable" and "pending" column of dm-timer is set to false false always which is incorrect i assume, "enable" column must be set to true leaving "pending" toggle with generation of interrupt each time.Is that correct ??Even my app.cfg dm-timer box is checked. Below is the screen shot..Plz have a look.

    Regards

    Satyaprakash

  • Hi Satyaprakash,

    From the memory browser contents I can confirm that the current thread type is Hwi. I am not sure why ROV and CCS are having trouble interpreting the thread type. When you took the screenshot, was BIOS executing a Hwi function ?

    The Timer_stub__E Hwi is created by SYS/BIOS and is the SYS/BIOS clock's timer handler function and you are right the enabled field for this Hwi should be true.

    Summarizing all the problems you are seeing below:

     - BIOS module's ROV view shows an error.

     - The breakpoint in LCDIsr Hwi function is never hit if the Hwi is created statically. If the same Hwi is created dynamically the breakpoint is hit but only if a breakpoint is set at BIOS_start() also.

    Have I accurately summarized the issues you currently have ?

    Best,

    Ashish

  • Hi Ashish

    Yes you are absolutely correct, when i captured the screen shot , Bios was executing Hwi.

    Ashish Kapania

    Have I accurately summarized the issues you currently have ?

    Yes you have understood the problem correctly..."Thanks".

    And one more thing, which part of the memory browser contains data regarding "current thread type"?

    Regards

    Satyaprakash

  • Hi Ashish

    Yes you are absolutely correct, when i captured the screen shot , Bios was executing Hwi.

    Ashish Kapania

    Have I accurately summarized the issues you currently have ?

    Yes you have understood the problem correctly..."Thanks".

    And one more thing, which part of the memory browser contains data regarding "current thread type"?

    Regards

    Satyaprakash

  • Hi Satyaprakash,

    I used the memory browser dump that you had shared to determine the current thread type. The BIOS_module__state structure definition can be found from the ti/sysbios.BIOS.h header file:

    Once you have the structure definition, you can determine the offset of threadType field (It is the 6th word in this case).

    Best,

    Ashish