• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1791 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

Christoph Sulzbachner
Prodigy 120 points

Other Parts Discussed in Thread: TMS320C6747

Hi,

I am using the following setup:

- C6455 DSP with the EDMA, GPIO, INT, EMIF, SRIO, EMAC peripherals

- DSP/BIOS 5.33.06

- CGTools 6.1.12

- NDK 2.0.0.0

My project runs a time and halts at UTL_halt. I placed a breakpoint on the exception vector, at a label called 'hwi1'. When the application stops there, the B3 register has a value that points to a valid instruction, that location differs. I have already excluded the algorithms, getting the interrupts working.

The Message Log of Execution Graph Details show the message below:

1097622   SWI: end   KNL_swi (TSK scheduler) (0x8e4fc8) state = done
1097623   SEM: post <unknown handle> (0x8a593c) count = 47
1097624   SWI: post  processBufferSwi (0x8e4f70)
1097625   SWI: begin processBufferSwi (0x8e4f70)
1097626   SEM: post <unknown handle> (0x8a5e0c) count = 1
1097627   SWI: post  KNL_swi (TSK scheduler) (0x8e4fc8)
1097628   SEM: post <unknown handle> (0x8a591c) count = 0
1097629   SWI: post  KNL_swi (TSK scheduler) (0x8e4fc8)

(continue run,then halted at UTL_halt)

1097630   EXC_exceptionHandler: EFR=0x2
1097631     NRP=0xe0137d80
1097632     mode=supervisor
1097633   Internal exception: IERR=0x10
1097634     Resource conflict exception
1097635   SYS abort called with message 'Run-time exception detected, aborting ...'

I do not modify the task context during runtime. Maybe the NDK or the scheduler does this. I am using a task switch hook function for checking the task stack, system stack and logging the previous and next task. This is the only piece of code working on the task context.

Regards,

Christoph

  • 0
    TI__Expert 4125 points

    Maybe you are blowing a stack(s)? Check the stack usage in KOV to see how close you are. You will not always catch it using the task switch hook.

  • 0
    TI__Mastermind 18260 points

    It appears that your program has "jumped into the weeds", since the NRP address doesn't appear to be valid memory and since a Resource conflict exception should never really result from C code (but could easily result from interpreting random data as asm instructions).

    You say that B3 is at a valid instruction (but differs between different runs).  That might be a good clue.  If B3 corresponds to a "branch return location" and the branch from which it would be returned to is a branch through a register (as opposed to a PC-relative branch to a label), then see if that branch register contains an address similar to the NRP value.  If so, then the branch target value in that register has been loaded badly, and you can backtrace from there to see how that register got loaded with the bogus value.  It could easily be as Mark says, that you have blown a stack.

    Regards,

    - Rob

     

  • 0 in reply to Robert Tivy
    Intellectual 355 points

    Hi Christoph,

    I am having a similar issue, but I am using a TMS320C6747.  Did you ever figure out what was causing this?

  • 0 in reply to Eric Hereford
    Prodigy 120 points

    Hi Eric,

    The problem was the following: The Serial Rapid IO peripheral was writing data to a specific memory location that was further processed by the DSP. The processing was triggered by an interrupt initiated by a SRIO doorbell. For data acquisition I implemented an input buffer that was able the handle n SRIO bursts. The resource conflict occurred when the input buffer was full and I used to process memory that was written by the SRIO peripheral at the same time. Now, before data processing I'm using a IDMA transfer to copy the required data to another memory position and process the data there.

    Regards,

    Christoph