Program Exit unexpectedly at rts64plus.lib [exit.obj (.text:_abort)]

abort is the catchall for program termination, whether it terminated successfully, in failure, or due to a fault. You need to figure out what code was executing immediately before the call to abort.

Hi

Thanks for your response. This exit happens in b/w a continuous data transfer and processing logic i implemented for an application and now i trying to trace back from the exit address shown at debug for finding exact reason for exit. Since this exit happens to the call at address 88131fa0 00000020 : exit.obj (.text:_abort) as its shown in .map file; the function very close as map file say's is DataTransfer() ;

Kindly suggest whether i can trace back and find the information/ clue to the exit reason which happen at this address. Moreover with SYSBIOS .cfg i made the RTSLib re-entreent

Thanks

Hi

Can you help me to trace the sequence of code as shown in map file??? Is thre any way to relate this sequence from map file to code related to that using any techniques. Tha exit is the place where my program aborts?????

 

8131da0 00000040 SDR_NC_HDR_Wf_LLC_p64P.o64P (.text:_xdc_runtime_System_printf__E)

88131de0 00000040 ti.targets.rts6000.a64P : System.o64P (.text:_xdc_runtime_System_putch__F)

88131e20 00000040 : Text.o64P (.text:_xdc_runtime_Text_ropeText__F)

88131e60 00000040 SDR_NC_HDR_Wf_LLC_p64P.o64P (.text:_xdc_runtime_Text_visitRope__I)

88131ea0 00000020 Data_Transfer.obj (.text)

88131ec0 00000020 ti.targets.rts6000.a64P : xdc_noinit.o64P (.text:___xdc__init)

88131ee0 00000020 rts64plus.lib : negll.obj (.text:__negll)

88131f00 00000020 : _lock.obj (.text:__nop)

88131f20 00000020 : printf.obj (.text:__outc)

88131f40 00000020 : printf.obj (.text:__outs)

88131f60 00000020 : _lock.obj (.text:__register_lock)

88131f80 00000020 : _lock.obj (.text:__register_unlock)

88131fa0 00000020 : exit.obj (.text:_abort)

88131fc0 00000020 : remove.obj (.text:_remove)

88131fe0 00000020 sysbios.a64P : BIOS.obj (.text:_ti_sysbios_BIOS_getCpuFreq__E)

88132000 00000020 : BIOS.obj (.text:_ti_sysbios_BIOS_nullFunc__I)

88132020 00000020 : BIOS.obj (.text:_ti_sysbios_BIOS_setThreadType__E)

88132040 00000020 : BIOS.obj (.text:_ti_sysbios_BIOS_start__E)

Shino Samuel said:

Can you help me to trace the sequence of code as shown in map file?

The map file shows how the functions are laid out in memory.  That has nothing to do with order in which the functions are executed.

We compiler experts lack the expertise to help you at this point.  I'll get some help on this thread.

Thanks and regards,

-George

Are you able to run the application and reproduce the problem inside the CCS debugger? If so, that will be a big help in finding the problem.

yes this error will happen within an hour. So i can reproduce the problem inside CCS debugger .

Thanks

Please do that, and inspect the value of B3 (return address register) when you reach the C$$EXIT breakpoint. This should be an address that is inside the function that called abort or exit. Knowing this function should be a clue as to why abort or exit was called. If the function is a helper function like std::terminate, set a breakpoint on that function and restart to see where the helper function was called. Repeat as needed.

What we really want to know is the call stack. If CCS shows you the call stack, then great. If not, we need to reconstruct it the hard way. If you understand how the C calling convention saves and restores registers, you might consider unwinding the stack by hand to find the calling function. This is tedious and error-prone, but it might be faster than running the whole program over and over again. What version of the compiler are you using (this is not the same as the CCS version or the BIOS version).

Hi Friend,

I tried to trace back the abort issue from your input and found it as an exception which throws on L1/L2 cache fault. Now i try to see the issue in detail why it happen randomly and is there any relation with SDMA using with the McBSP interface for data transfer in generating cache fault? Presently i was using internal memory RAM for ping-pong receive using SDMA from McBSP, i believe there is no issue of cache invalidate in this case.

If someone can suggest the possible reason for L1/L2 cache fault & associated exceptions, it will help me a lot..........

Thanks for your support.

Hi,
What is your processor ?
Is this your own example or TI provided ?

Did you check the cache invalidate "return" value for requested memory ?
Did you enable corresponding MAR bits to enable cache ?

processors.wiki.ti.com/.../Cache_Management
processors.wiki.ti.com/.../Enabling_64x%2B_Cache

Shino,

In addition to Titus' questions, especially the specific processor you are using, please identify how you determined that the exception was for an L1/L2 fault. You are using C64xp libraries, but I can find no exception reference for that core that would reference an L1/L2 cache fault.

If you have a second board, please see if you get the same results on another one, in case this is a problem within your specific device on your first board.

Regards,
RandyP

Hi Randy,

I got L1/L2 fault information from ROV , which is printed to SysMin Module of SYSBIOS. Presently I was using OMAP3530 DSP side  with SYSBIOS version bios_6_37_03_30 . The entire application is LLC Layer of High Data Rate Waveform for IP based application on SDR Radio.  

Presently working on custom Platform developed by us, based on TI's OMAP3530 with Linux on ARM side and SYSBIOS DSP Application on DSP side.  Entire DSP application is using the 4MB space allocated in agreement with two cores on DDR region with L1/L2 cache enabled at DSP. The entire application is running with SYSBIOS scheduling, we create tasks dynamically based on the IP services. Moreover we are using Queues and all memory management functions (malloc, free and so on....) of rts library with re entrantcy option set to GateMutex  for rtslibrary.

Later we put debug points  and found that the this happens during the pre-emption of  task with swi . Furthermore dynamically we create task based on IP services with same priority to all task so this is not the same case for multiple tasks.  This error will disappear if we disable swi and restore after execution of each sequence. The  reason is still unknown, but we took this input from TI document itself. 

Finally, I think this is to be discussed with a SYSBIOS experts too....

 

Thanks & Regards,

Shino,

When you are ready to post to the E2E TI-RTOS Forum (new name for all DSP/BIOS and SYS/BIOS products), please tell them your settings from your configuration files and the method you use to post the problematic SWI. They will need all of this information, and more, if you suspect a problem with the operation of SYS/BIOS.

From your latest information, I would suggest a possible stack overflow as a concern to be examined. Try increasing the size of your system stack, and even your task stacks, to see if it helps with your problems.

Shino Samuel said:

I got L1/L2 fault information from ROV , which is printed to SysMin Module of SYSBIOS.

Please show us exactly what you saw printed. The OMAP3530 support is provided in another E2E forum (I know, we make it confusing to figure it all out). If the problem is generic to C64x+ then we may have some useful insights here, but as I said, I could find no references to this fault in what I looked at. Of course, that was before you told us which chip you were using. Your exact printout messages will be helpful in getting rid of any further mistakes like that on our part.

Shino Samuel said:

The  reason is still unknown, but we took this input from TI document itself. 

Which TI document are you referring to, and where in that document? Which input are you talking about here?

Regards,
RandyP