• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1743 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.

How to use: ABORT FXNs in SYS/BIOS 6?

Santosh Pinto
Expert 1010 points
Other Parts Discussed in Thread: SYSBIOS

I would like to port the abort() and error() functionality example to

The examples given are for DSP BIOS 5.

Please help to port the following code to SYS/BIOS 6.3 used in CCS 5.0.

var SYS      =   xdc.useModule('ti.bios.SYS');

SYS.ABORTFXN = "Lte_SysAbort";//_Lte_SysAbort;//"_Lte_SysAbort";

 

 

Regards

Santosh 

  • 0
    Expert 1010 points

    Kindly suggest the examples for handling abort() and error() functionality using DSP BIOS 6.

    The suggested code base is for DSP SYS BIOS 5, now on reading the migration document of application from DSP/BIOS 5 to  SYS/BIOS 6, the SYS module "ti.bios.SYS" is replaced by "xdc.runtime.System". Ive got the example for SYS module of DSP/BIOS 5.

    Kindly help me to get examples for abort() and error() for SYS/BIOS 6.

     

    Thanks

    Santosh

  • 0 in reply to Santosh Pinto
    TI__Mastermind 32475 points

    Santosh,

    Are you completely moving your source code and configuration over to SYSBIOS 6.x?

    We do have legacy support for BIOS 5 in SYSBIOS 6.x which supports existing BIOS 5 APIs and configuration with a few required changes to the configuration.  The migrating docs should talk about this.

    If you are completely moving over the abort() can be dealt with System but the error() probably requires using Error.

    For abort(), you can try adding an 'at exit function' with System.atexit.  See the CDOC for System for more details.

    For error(), you might try the Error.raiseHook.  Again see the CDOC for Error for more details.

    Judah

  • 0 in reply to judahvang
    Expert 1010 points

    hello Judah,

    Yes. Im porting my current application from DSP/BIOS 5 to SYS/BIOS 6 along with the configuration file too.

    I tried using the System_atexit(System_AtexitHandler handler) providing the handler to be invoked in case of an assert or an abort.

    Now i call System_abort() from the main() function, but it doesnt hit the function handler attached to the System_atexit()

    But when i invoke the System_exit() from the main() function, it hits the handler.

    Seems like the handler attached with System_atexit() is only invoked in case of System_exit() and "NOT" in case of System_abort().

    Please verify this too and kindly suggest.

    Ive also seen that i fail to notice the Stack Contents ie as to the nesting of the function calls before the System_exit () is exactly called.

    So there are Two issues:

    1) System.atexit() function handler passed fails to invoke for System_abort(), it only invokes for System_exit().

    2) The Stack of functions called is not visible when the System.atexit() function handler is called.

    Im attaching the code with this post.

    2046.abort_exit_func_test.rar

    Thanks,

    Santosh

  • 0 in reply to Santosh Pinto
    TI__Mastermind 32475 points

    Santosh,

    The CDOC for System_abort states that System_abort does not call System_atexit handlers:

    System_abort:  This is called when an executable abnormally terminates. The System gate is entered, the SupportProxy's abort function is called and abort is called. No exit functions bound via System_atexit() or the ANSI C Standard Library atexit() functions are executed.

    For System_abort, you can pass in your own abort string.  What is your abort handler trying to achieve?  System_exit in SYSBIOS 6.x is like SYS_abort in DSPBIOS 5.x

    Unfortunately the call stack problem is not a problem of SYSBIOS.  Its an issue with the rts library not being built with debug information.  Thus any call into the rts library shows no call stack.  The only way to get around this is to rebuilt the rts library with debug information or include certain rts lib source files in your build.

    Having said all this, if you don't like the System proxy provided by SYSBIOS/XDC, you can create your own proxy and plug it into System.SupportProxy.  In this way, you can control what gets called for System_abort, System_exit, System_flush, System_putc, System_ready.

    xdctools provides 'xdc.runtime.SysStd' and 'xdc.runtime'SysMin' as examples.

    Judah

     

  • 0 in reply to judahvang
    Expert 1010 points

    Can you help me out in rebuilding the RTSC packages library with the Debug information or any kind of documentation which would help me in re-building the library ?

    This would help me in viewing the call stack when the System_abort() gets hit.

    Thanks

    Santosh

  • 0 in reply to Santosh Pinto
    TI__Mastermind 32475 points

    Santosh,

    I'm not sure if you understood what I said so I'm going to sound like I'm repeating myself but its not the RTSC stuff that doesn't have the debug information.  Its the runtime support library (rts.lib) provided by the TI codegen tools which isn't built with debug info.  These do not come in a RTSC package however, the sources for all of the rts.lib can be found in your codegen tools lib directory.  For example: C:\Program Files\Texas Instruments\ccsv5\tools\compiler\c6000\lib\rtssrc.zip.  The easiest way for you to try this out would be for you to extract those source files and include them into your project build.

    Having said that, if you want to provide your own SystemProxy so you can control what function System_abort() calls, you can try to add it and then build it with the XDCTOOLS by doing the following:

    1.  Follow steps 2.1-2.4 of the Bios Getting Started Guide.pdf.  This is to get your XDCPATH and such setup correctly.

    2.  Then you can rebuild using the xdctools with the following command:  "xdc -PR ."   This command will recursively descend the current directory and subdirectories and build any RTSC package it finds.

    Judah

  • 0 in reply to judahvang
    Expert 1010 points

    Thanks Judah,

    I was able to check out the Stack during an abort() / exit() using the debug build rts.lib containing the debug information.

     

    Santosh