• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 3217 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

exception analysis

Mohammed Fawzy
Expert 1860 points
Other Parts Discussed in Thread: SYSBIOS

hi,

I'm using TI-RTOS version "irtos_tivac_2_00_02_36" for TM4C129 controller that run on the DK129, I had a fault during debugging but I don't know how to find the cause of the fault, SO please help.

here is the ROV HWI exception data

Decoded exception,
Decoded,Hard Fault: FORCED: BUSFAULT: PRECISERR.Data Access Error. Address = 0xfff04fbd
Exception context,
$addr,0x20019738
$type,ti.sysbios.family.arm.m3.Hwi.ExcContext
threadType,ti.sysbios.BIOS.ThreadType_Swi
threadHandle,0x2001a27c
threadStack,0x20017898
threadStackSize,8192
r0,0xfff0
r1,0xfff04fbd
r2,0x0
r3,0x20019dc4
r4,0x21a0d
r5,0x1
r6,0xfff04fbd
r7,0xc35
r8,0x2001a300
r9,0x2bdec
r10,0x2bf92
r11,0x0
r12,0x13380300
sp,0x20019810
lr,0x108c7
pc,0xf454
psr,0x1000000
ICSR,0x803
MMFSR,0x0
BFSR,0x82
UFSR,0x0
HFSR,0x40000000
DFSR,0xb
MMAR,0xfff04fbd
BFAR,0xfff04fbd
AFSR,0x0
Exception call stack,
0    ti_sysbios_knl_Clock_workFunc__E() at :0,PC = 0x0000F454 FP = 0x20019810
1    abort() at exit.c:117,PC = 0x0001EC7F FP = 0x20019810
2    ti_sysbios_knl_Task_startup__E() at :0,PC = 0x2001A27C FP = 0x20019818
3    abort() at exit.c:117,PC = 0x0001EC7F FP = 0x20019818
4    ti_sysbios_knl_Task_startup__E() at :0,PC = 0x200199B4 FP = 0x20019820
5    abort() at exit.c:117,PC = 0x0001EC7F FP = 0x20019820
6    <symbol is not available>,PC = 0x00000002 FP = 0x20019828

  • 0
    TI__Genius 10825 points

    Mohamed,

    This may be due to insufficient system stack in your application. What is the stack size for your application? Can you increase the stack size, rebuild and test?

    You can change stack size in your .cfg file:

    Open .cfg file. Browse through TI-RTOS Welcome Page > System Overview > TI-RTOS Kernel > Runtime.

    Hope this helps.

    Vikram

  • 0 in reply to Vikram Adiga
    Expert 1860 points

    Vikram,

    you are correct the problem was in the stack but not the system stack but in one of the tasks which had large size local variable in one of its functions, but I discovered it by reviewing the code, So is there is a way to discover the problem from the exception information? in other meaning how can I read the exception information to put my hands on the problem?

    Thanks,

    Mohamed Fawzy

     

  • 0 in reply to Mohammed Fawzy
    TI__Genius 10825 points

    Mohamed,

    The ROV tool (in Debug mode, open Tools > ROV) can be very useful in these cases. In ROV, you can use the BIOS -> Scan For Errors view to check for errors. Also, if you open the Task view in ROV, the stack peak value would be in red text when stack overflow is detected.

    Hope this helps.

    Vikram

  • 0 in reply to Vikram Adiga
    TI__Genius 10825 points

    Correction: The stack peak value would be in red background not red text when stack overflow is detected. Hover your mouse over the value, a pop-up will display error message.

  • 0 in reply to Vikram Adiga
    Expert 1860 points

    Vikram,

    actually, I noticed that I have red box in field "blockedon" for another task not the real task, please check the attached photo.

    but my major concern, how can I debug the problem if it happened @ the client without debugger, if I were not able to trace the problem based on the exception information?

    Than ks,

    Mohamed.

  • 0 in reply to Mohammed Fawzy
    TI__Genius 10825 points

    Mohamed,

    I am not sure how to trace such a problem without debugger unless you log some debug outputs from client and look hard at your code flow to see where the issue is.

    Another suggestion would be look at the fault status register (see your first post) and go through ARM technical reference manual to understand the cause of the problem. But in case of stack overflows, this may sometimes be a false alarm if some critical data structures are overwritten. There may be data faults, pre-fetch aborts if instructions get overwritten. If stack overflows but does not overwrite critical structure, the kernel will be able to detect it when it enters idle mode.

    Stack overflows are always tricky. You would need the combination of debug tools to generally figure out issues.

    Vikram