• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 467 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.

"Resource Conflict Exception" Crash following exit from main

nchukeg
Intellectual 380 points
Other Parts Discussed in Thread: OMAPL138

Hello,

We are using OMAPL138

DSP/BIOS version bios_5_41_10_36

Following the exit from main() we have a hard fault issue "Resource Conflict Exception"

NRP points to the line in KNL_queues() function

The KNL_queues function looks as follows:

0x0082FD78:   0082FD78            LMBD.L1X      A23,B0,A1
0x0082FD7C:   0082FD78            LMBD.L1X      A23,B0,A1
0x0082FD80:   0082FD80            MPYSU.M1X     A23,B0,A1
0x0082FD84:   0082FD80            MPYSU.M1X     A23,B0,A1
0x0082FD88:   0082FD88            SET.S1        A0,23,29,A1
0x0082FD8C:   0082FD88            SET.S1        A0,23,29,A1
0x0082FD90:   0082FD90            B.S1          0x87156C (PC+268268 = 0x0087156c)
0x0082FD94:   0082FD90            B.S1          0x87156C (PC+268268 = 0x0087156c)
0x0082FD98:   0080A00C            LDHU.D2T1     *+B14[160],A1
0x0082FD9C:   0080A00C            LDHU.D2T1     *+B14[160],A1
0x0082FDA0:   0082FDA0            SHR.S1X       B0,0x17,A1
0x0082FDA4:   0082FDA0            SHR.S1X       B0,0x17,A1
0x0082FDA8:   0082FDA8            MVK.S1        0x05fb,A1
0x0082FDAC:   0082FDA8            MVK.S1        0x05fb,A1
0x0082FDB0:   0082FDB0            ANDN.S1X      A23,B0,A1
0x0082FDB4:   0082FDB0            ANDN.S1X      A23,B0,A1                              <= line after which crash happens

It looks like LDHU instruction above attempts to load the value into A1 which would appear 4 cycles later.  But, all of the instructions following LDHU use A1 as the destination.  So how can the compiler allow this?

The issue surfaced after we have moved certain memory sections around in the Memory Manager in the .tcf such that

Section 1

Segments for DSP/BIOS Objects

Segment For malloc/free

.stack

Task Manager Object Memory

Stack segment for dynamic tasks

Section 2

Everything else

--------------------------------------

This is a critical issue,

Thank you

Oleg

 

 

 

  • 0
    TI__Mastermind 18260 points

    nchukeg said:

    NRP points to the line in KNL_queues() function

    The KNL_queues function looks as follows:

    0x0082FD78:   0082FD78            LMBD.L1X      A23,B0,A1
    0x0082FD7C:   0082FD78            LMBD.L1X      A23,B0,A1
    0x0082FD80:   0082FD80            MPYSU.M1X     A23,B0,A1
    0x0082FD84:   0082FD80            MPYSU.M1X     A23,B0,A1
    0x0082FD88:   0082FD88            SET.S1        A0,23,29,A1
    0x0082FD8C:   0082FD88            SET.S1        A0,23,29,A1
    0x0082FD90:   0082FD90            B.S1          0x87156C (PC+268268 = 0x0087156c)
    0x0082FD94:   0082FD90            B.S1          0x87156C (PC+268268 = 0x0087156c)
    0x0082FD98:   0080A00C            LDHU.D2T1     *+B14[160],A1
    0x0082FD9C:   0080A00C            LDHU.D2T1     *+B14[160],A1
    0x0082FDA0:   0082FDA0            SHR.S1X       B0,0x17,A1
    0x0082FDA4:   0082FDA0            SHR.S1X       B0,0x17,A1
    0x0082FDA8:   0082FDA8            MVK.S1        0x05fb,A1
    0x0082FDAC:   0082FDA8            MVK.S1        0x05fb,A1
    0x0082FDB0:   0082FDB0            ANDN.S1X      A23,B0,A1
    0x0082FDB4:   0082FDB0            ANDN.S1X      A23,B0,A1                              <= line after which crash happens

    That is not actual code, but instead it is a disassembly interpretation of data.  KNL_queues is an array of QUE objects (just next/prev pairs).  It has one QUE object per priority.  As you can see, each "instruction" is actually a pointer to either the QUE element itself (for empty priorities) or a QUE element in a TSK object (since that priority apparently has at least one TSK that is ready to run).

    So, I assume the NRP value was near 0x0082fdb4.  If so, your code "went into the weeds" and started executing data, which will almost always result in an exception.

    If NRP *is* near 0x0082fdb4, then you need to figure out how it got there.  Register B3 is a nice "bread crumb", either indicating where you last returned from a function call, or indicating where you will return from the current "function" (quotes because you're not really in a function or any code for that matter).  Position the disassembly window on the address in B3, and see if there is a branch instruction just above that B3 address.  If so, it probably branched through a register, and if it did then you will see an address near 0x0082fdb4 in that "branch register".  Your next step is to figure out why that branch register was loaded with that bogus value.  Probably from some corrupted function pointer in a struct somewhere.

    Regards,

    - Rob