• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 825 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.

Opcode exception resource conflict after adding an interrupt

Marthijn Bloemberg
Prodigy 190 points
Other Parts Discussed in Thread: SYSBIOS, TMS320C6672

Hello all,

I've got a problem with my code that when I define a second interrupt, my program does not work properly anymore. It runs an xml parser which is triggered by the first interrupt and parses some xml data. That part works without defining the second interrupt, but when it is defined i get an Opcode exception halfway.

I've set a breakpoint in the second interrupt routine to see if it does something with the memory location, but the second interrupt routine isn't even called yet.

I know that the exception means that i've got an overflow or a corrupt memory location. but here comes the problem, there isn't an overflow and the functionpointer at the memorylocation which is "corrupted" is already called several times at the point where the exception comes.

I've used the memory browser to see if something overrides the location but that is not true.

The program works again when i delete the second interrupt.

Can anyone tell me where to look further?

Thanks,
Marthijn

  • 0
    TI__Mastermind 32475 points
    Please let me know what device you are on? What version of SYSBIOS and/or CCS are you are using?

    Typically an opcode exception means that its executing in some bogus address space.
    When the exception occurs, you can look at:
    1. NRP register [This tells you where the exception was triggered, typically a couple of cycles after the exception happened].
    2. B3 - this is the return ptr address (where you would have return to without the exception)

    With these two registers, you should be able to determine where in the code the exception is occurring. Then you can try to find out how, it got into that state.

    Judah
  • 0 in reply to judahvang
    Prodigy 190 points
    the device is a tms320c6672, the SYSBIOS version is 6.33.6.50 and my CCS is 5.2.0.

    The full error code is:

    [C66xx_0] 0x803770 A11=0x804504
    A12=0x0 A13=0x0
    A14=0xc238564 A15=0x0
    A16=0xc237cc8 A17=0x3fffffff
    A18=0x0 A19=0x0
    A20=0x0 A21=0x0
    A22=0xd103d7a4 A23=0x86008002
    A24=0xc8fa31a A25=0x732efeab
    A26=0x24fd2725 A27=0x0
    A28=0x400 A29=0x0
    A30=0x1 A31=0x0
    B0=0x1 B1=0x0
    B2=0x[C66xx_0] 0 B3=0xc211426
    B4=0x80140000 B5=0xc2386a6
    B6=0x6640010 B7=0x20
    B8=0x805600 B9=0x40490000
    B10=0x804da8 B11=0x0
    B12=0x0 B13=0x0
    B14=0x805ba8 B15=0x8036e8
    B16=0x0 B17=0xc237cc8
    B18=0x2d B19=0x3feff800
    B20=0x3f7e16bd B21=0x40cb0060
    B22=0xf B23=0x0
    B24=0x696760[C66xx_0] 1c B25=0xee53a9c5
    B26=0x10182149 B27=0x2800c017
    B28=0x0 B29=0x0
    B30=0x1 B31=0x0
    NTSR=0x1020f
    ITSR=0x20d
    IRP=0xc210e24
    SSR=0x0
    AMR=0x0
    RILC=0x0
    ILC=0x0
    Exception at 0xc2114c8
    EFR=0x2 NRP=0xc2114c8
    Internal exception: IERR=0x18
    Opcode exception
    Resource conf[C66xx_0] lict exception
    ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0x0c2114c8, sp = 0x008036e8.
    To see more exception detail, use ROV or set 'ti.s[C66xx_0] ysbios.family.c64p.Exception.enablePrint = true;'
    xdc.runtime.Error.raise: terminating execution

    When I step into the function at 0x0c2114c8 it breaks this error. It is the only breakpoint I have at the moment and the program appears to stop and continue 2 times and the 3th time it breaks.

    You think the error is between NRP and B3?
    Might there be some way that in between the second and the third time the memory location is overwritten thanks to the second hwi added to the code? It sounds weird but this error is gone when the second hwi is gone.
  • 0 in reply to Marthijn Bloemberg
    TI__Mastermind 32475 points
    Well, if you're able to reproduce the problem with breakpoints...then I suggest you run it 2x and on the third time, single step to see if you can see the problem.

    Its not weird at all that a second interrupt introduces this problem...that typicall of race conditions and errors like this.

    NRP gives you a general idea of where the excpetion occurred. Typically a few instruction cycles before the address in NRP because when the exception occurs, it takes a few cycles in the pipeline before it triggers.

    In the past, I've seen branches through one of the A or B registers that contain 0.

    Judah