• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 2403 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.

Opcode exception, and using ROV

Chris Jagielski
Expert 1630 points
Other Parts Discussed in Thread: SYSBIOS

Hello all,

I have a run-time opcode exception.  I have read other threads on e2e about this as wells the RTSC page about ROV.  I'm sure that I have a simple program, but I can't seem to debug it on my own yet.

Note: my project is very simple.  I started with the SYS/BIOS "typical" example, and I added some of my proprietary algorithm C code in an idle loop.  For now, I'm just trying to get it to run on a single C6678 core and time it's clock cycles (which I've already done successfully with other algorithms of mine, without problems).

 

To debug, I set a few breakpoints.  The first breakpoint is in main() right at BIOS_start().  Unfortunately, I get this Exception error output when I step over that line... so it's basically at the very first thing that happens in my program.  (By the way, my test code is just inside an idle loop. Very simple!).

What is the best way to proceed troubleshooting from here?  I'm hoping to learn more about ROV and SYS/BIOS along the way, so I appreciate any guidance.

Here is the Console output I get:

[C66xx_3] A0=0x0 A1=0x3
A2=0x3 A3=0x90
A4=0x0 A5=0x86
A6=0x0 A7=0x8607c0
A8=0x84e3be A9=0x0
A10=0x0 A11=0x2
A12=0x849cf0 A13=0x2
A14=0x84e3be A15=0x0
A16=0x8607b0 A17=0x1
A18=0x8607a4 A19=0x860794
A20=0x8607ac A21=0x86079c
A22=0x8607a8 A23=0x8607b4
A24=0x1 A25=0x8607bc
A26=0x860798 A27=0x8607b8
A28=0x860788 A29=0x860790
A30=0x30 A31=0x1
B0=0x30 B1=0x1
B2=0x860780 B3=0x8622f8
B4=0x860770 B5=0x8420c8
B6=0x84d9f4 B7=0x84fd54
B8=0x2 B9=0x860748
B10=0x860778 B11=0x8607c0
B12=0x86077c B13=0x860784
B14=0x862360 B15=0x8606a0
B16=0x84f2fc B17=0x0
B18=0x3f645134 B19=0x80a1a57a
B20=0x9e1d0000 B21=0x8606d8
B22=0x0 B23=0x8606d8
B24=0xffffffff B25=0xffffffff
B26=0xfffffff7 B27=0x0
B28=0x66666666 B29=0x30666666
B30=0x8c1197f1 B31=0x1a9ea
NTSR=0x0
ITSR=0x2
IRP=0x84d9f4
SSR=0x0
AMR=0x84eb90
RILC=0x0
ILC=0x0
Exception at 0x8607cc
EFR=0x2 NRP=0x8607cc
Internal exception: IERR=0x8
Opcode exception
ti.sysbios.family.c64p.Exception: line 255: E_exceptionMin: pc = 0x38842d9c, sp = 0x0084fd54.
To see more exception detail, use ROV or set 'ti.sysbios.family.c64p.Exception.enablePrint = true;'
xdc.runtime.Error.raise: terminating execution

  Thank you for your help!!  My system:

  • CCS  5.4.0.00091
  • MCSDK  2.0.2.06
  • SYSBIOS  6.35.3.47 (IDE Client)
  • (running on Ubuntu)
  • 0
    TI__Mastermind 45025 points

    Hi Chris,

    The app won't return from BIOS_start, so stepping over won't tell you much, other than that your app crashed somewhere after the kernel started running.

    Can you check the Task stacks in ROV?  Do you see any overflows?  You should also check the Hwi stack.

    Chris Jagielski said:
    I added some of my proprietary algorithm C code in an idle loop.

    Can you try a simple experiment?  Can you surround your algorithm code with a #if 0 / #endif?  To essentially take your algorithm out of the picture?

    Do you still get the exception at this point?  If not, then it's probably safe to say that some code in your algorithm is behaving badly and you need to trace which line of code is causing the exception.

    Please refer to this wiki to see how to use that exception dump output to trace back to where the exception happened.

    Steve

  • 0 in reply to Steven Connell
    Expert 1630 points

    Steve, this is incredibly helpful.  Thank you for taking the time to type this response.

    To simplify things, I created a new project and added 1 Task (that I created statically).  I put my C algorithm into that Task.

    Steven Connell said:

    The app won't return from BIOS_start, so stepping over won't tell you much, other than that your app crashed somewhere after the kernel started running.

    Can you check the Task stacks in ROV?  Do you see any overflows?  You should also check the Hwi stack.

    Yes, now I see a stack overflow for my task.  I tried doubling it to 16,348.  This gave me a compile warning that the "stackSize was adjisted to guarantee proper alignment", and I see it is actually 16,352.  I'm guessing this is just a minor detail, and nothing about which I should be concerned, correct?

    Now when I pause, it says the task is "blockedOn" an invalid address (0x0), which is obviously not within the task's stack.

    Steven Connell said:

    You should also check the Hwi stack.

    Why did you suggest to check the Hwi stack?  Since I haven't created any HWI's, should it be doing anything?

    Steven Connell said:

    Can you try a simple experiment?  Can you surround your algorithm code with a #if 0 / #endif?  To essentially take your algorithm out of the picture?

    Do you still get the exception at this point?  If not, then it's probably safe to say that some code in your algorithm is behaving badly and you need to trace which line of code is causing the exception.

    It definitely was my algorithm behaving badly.  Now I'm trying to see why the stack pointer goes to 0x0, so I'll follow your advice and comment out sections of my algorithm at a time until it works.

    Steven Connell said:

    Please refer to this wiki to see how to use that exception dump output to trace back to where the exception happened.

    This is a great resource, thanks.

    Unfortunately, my Exception Dump went away and now it just sits there doing nothing.  I'm sure it's still the same problem, I just need to do some more digging to understand it.  I'll comment-out parts of my algorithm to slowly build it back up.

  • 0 in reply to Chris Jagielski
    Expert 1630 points

    Steve,

    Why did you suggest to check the Hwi stack? Since I haven't created any HWI's, should it be doing anything?

  • 0 in reply to Chris Jagielski
    TI__Mastermind 45025 points

    Hi Chris,

    There still may be Hwis running in your system, even though you didn't explicitly create any yourself (for example, all BIOS apps have a timer interrupt that goes off every millisecond).

    So, I didn't really expect that stack to be overflowing; it was more of a general debug technique.

    Steve

  • 0 in reply to Steven Connell
    Expert 1630 points

    Thanks Steve!  I had no idea that was there so I'm glad I'm learning.