• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 1630 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, NRP in _KNL_queues

Carl Miller
Intellectual 260 points
Other Parts Discussed in Thread: OMAP-L138

I'm developing an application for the DSP core of an OMAP-L138, using the uPP interface to an FPGA, and DSPLink message queues to the ARM core.  The application runs correctly for a short time, then abruptly ends up in UTL_halt().  With my limited JTAG capability, I've managed to tease the following out of the system log....

 

375E EXC_exceptionHandler: EFR=0x2
3760   NRP=0xc2433994
3762   mode=supervisor
3764 Internal exception: IERR=0x10
3766   Resource conflict exception
3768 SYS abort called with message 'Run-time exception detected, aborting ...'

 

According to my link map, 0xc2433994 falls at offset 0x6c into the _KNL_queues symbol....

 

c243357c   _QUE_ATTRS
c2433580   ___atexit_func_id__
c2433928   _KNL_queues
c24339c8   _KNL_dummy
c2433b9c   _debugLevel
c2433b9d   _upp_initialized
c2433ba0   _uppParams
c2433bc0   _uppChanparamA
c2433c14   _uppChanparamB

 

At this point, I'm not sure how to proceed in debugging this.  Any pointers would be much appreciated.

 

OMAP-L138 running DSP/BIOS 5.41.3.17 and DSPLink 1.65.0.2 from the TI DVSDK  OMAP-L138 EVM package 4.2.0.6.  I based my application code off of the Upp sample application from BIOS/PSP 1.30.1, and pulled the Upp driver from the same into my application.  So far my application is doing very little; basically it just reads from one Upp channel, and writes that data back verbatim to the other Upp channel, occasionally passing a message with performance statistics back to the ARM via a DSPLink message queue.

  • 0
    TI__Mastermind 30830 points

    Carl,

    The resource conflict exception usually occurs when an application has "derailed" and has started executing data.

    The bogus NRP value tends to support that theory in your case.

    This can happen for a number of reasons:

    1) Stack overflows (task stack or interrupt stack). Try increasing the stack sizes and see of the problem goes away.

    2) Uninitialized data or function pointers. Data structures that contain function pointers within them are notoriously vulnerable to this problem.

    3) Data structure or code corruption due to multi-processor memory overlap.

    4) Cache incoherency due to improper multi-processor shared data structure cache refreshing.

    These are just a few ideas that come to mind. Hopefully these might lead you to a solution.

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 260 points

    Thanks for the pointers, Alan.  It looks like I got it.  I was creating the main application task dynamically, like the uPP demo sample application does, and accepting all defaults for the task attributes.  When I started passing a task attributes structure to the TSK_create() call that specifically asked for a 32kB stack for that task, the problem went away.