• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 1836 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/AM3357: How to avoid HwiProxy

Benedikt
Prodigy 210 points
Part Number: AM3357
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Dear Supporters,

Our firmware application under development does not require portability from the AM335x target to other SYS/BIOS-capable controllers. Therefore, I have replaced the ti/sysbios/hal/Hwi module by the specific implementation ti/sysbios/family/arm/a8 in my application.

Still, the TI RTOS libary (we currently use 6.42.3.35) uses the generic Hwi interface. Hence, all critical sections use ti_sysbios_hal_Hwi_HwiProxy_disable__E() and its respective restore/enable counterparts instead of the shorter functions ti_sysbios_family_arm_a8_intcps_Hwi_disable etc., especially in the important parts like in the scheduling and inter-task communication modules (tsk.c, Semaphore.c etc.). In profiling, I see about 4.7% of CPU load only for the HwiProxy wrappers (load value is without the load of ..._intcps_Hwi kernel functions, which add another 7.1% !!!).

Can I configure the SYS/BIOS library to get rid of the unused proxy wrappers? What do you suggest? Any help is appreciated...

Best wishes,

Benedikt

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 22760 points

    Hi Benedikt,

    SYS/BIOS hal Hwi should be overriding the calls to HwiProxy_disable()/restore() with macros that call intrinsic functions (e.g, _disable_IRQ()).  Are you seeing the HwiProxy_disable()/restore() functions in your map file?  I tried to reproduce this, and don't see the HwiProxy functions in my .map file.

    Best regards,

    Janet

  • 0 in reply to janet
    Prodigy 210 points

    janet said:
    SYS/BIOS hal Hwi should be overriding the calls to HwiProxy_disable()/restore() with macros that call intrinsic functions (e.g, _disable_IRQ()).  Are you seeing the HwiProxy_disable()/restore() functions in your map file?  I tried to reproduce this, and don't see the HwiProxy functions in my .map file.

    Hello Janet,

    Yes, I am. The generic function ti_sysbios_hal_Hwi_disable__E() is defined in your Hwi.c module (and it does appear in my map file). It calls the respective proxy function ti_sysbios_hal_Hwi_HwiProxy_disable() in the XDC-generated code. The latter calls the target-specific function ti_sysbios_family_arm_a8_intcps_Hwi_disable(), which includes the essential inline assembler code to disable the interrupts.

    On the debugger, I can follow this call sequence. The HwiProxy function in the middle additionally saves some registers and creates another stack frame before invoking the family function (please note that we have to use the GCC without optimisation). Here, you can see what is actually called in our build:

    Best regards,

    Benedikt

  • 0 in reply to Benedikt
    TI__Mastermind 22760 points

    Hi Benedikt,

    Are you using the GNU toolchain?  I can reproduce the problem using GNU tools.  In my previous post, I had used the TI tools and did not see the problem.  This looks like a bug in BIOS, and I have filed a bug report (SYSBIOS-436: Hwi_disable()/Hwi_restore() not inlined for gnu A8F target).

    I was able to work around by modifying the file ti/sysbios/hal/Hwi__epilogue.h, by changing the lines:

    #if ((defined(xdc_target__isaCompatible_v7A9)) || \
         (defined(xdc_target__isaCompatible_v7A8)))


    to

    #if ((defined(xdc_target__isaCompatible_v7A9)) || \
         (defined(xdc_target__isaCompatible_v7A8)) || \
         (defined(xdc_target__isaCompatible_v7A)))

    Then I thought that instead of modifying BIOS code, I could just add

    BIOS.customCCOpts = "-Dxdc_target__isaCompatible_v7A8=1";

    to my .cfg file, but I got a build error with that, so unfortunately that is not a work-around.

    Best regards,

    Janet

  • 0 in reply to janet
    Prodigy 210 points

    Hello Janet,

    janet said:
    I can reproduce the problem using GNU tools.  In my previous post, I had used the TI tools and did not see the problem.  This looks like a bug in BIOS, and I have filed a bug report (SYSBIOS-436: Hwi_disable()/Hwi_restore() not inlined for gnu A8F target).

    Thankyou for testing with the GNU tool chain. Our project is in a critical phase, so I consider this an urgent issue.

    janet said:
    I was able to work around by modifying the file ti/sysbios/hal/Hwi__epilogue.h, by changing the lines [...]

    At the moment, I only have the Sys/Bios library and headers, with the code in my TI installation directory, but I could not find any CCS/Eclipse build project/configuration for the Sys/Bios library sources. Could you please send me the bios library build configuration (or point out where to find it)?

    Best regards,

    Benedikt

  • 0 in reply to Benedikt
    TI__Mastermind 22760 points

    Hi Benedikt,

    SYS/BIOS installations come with source code and a bios.mak for rebuilding.  If you don't have these, maybe you can get the installation here:

    To rebuild, you need to edit the bios.mak file at the top of the installation, to set XDC_INSTALL_DIR and gnu.targets.arm.A8F.  For example, for my windows installation, I set these to:

    XDC_INSTALL_DIR ?= c:/ti/xdctools_3_30_06_67_core
    gnu.targets.arm.A8F ?=C:/ti/ccsv6.1.0.00104/ccsv6/tools/compiler/gcc-arm-none-eabi-4_8-2014q3

    Then you can run gmake -f bios.mak

    Best regards,

    Janet

  • 0 in reply to janet
    Prodigy 210 points
    Hello Janet,

    Thanks for the information. I am going to try using a self-built version of the bios library. Still, I am interested in the outcome of the bug report you mentioned (SYSBIOS-436). Please keep me informed. Thanks in advance.

    Best regards,

    Benedikt