What causes me to land at C$$EXIT$hide, abort$hide?

Chuck,

Was there any other information printed to the console when this happened?  Such as a register dump?

To find out what the cause of this is, I suggest that you trace backwards using the B3 register.  For C6000 DSPs, the B3 register contains the return address of the instruction that called the function that the PC is currently in (and so will take you to code that got you there).

The general strategy is run your program until you hit one of the above symbols.  Halt the program and enter "B3" into the address in the dis/assembly window in CCS.  This should take you to the instruction that branched you to C$$EXIT$hide or abort$hide.  You can then scroll up in the assembly code to see which function you are in.

If you are lucky, that's as far as you need to go.  If it's an unfamiliar function, then you can try putting a break point at the location that "B3" brought you to, then restart and rerun.  Once you hit the break point you just set, you can again check B3 to see who called this function.  And so on.  You can repeat the process until you back track up the call stack to find the path that led you to those symbols.

Steve

Thanks, that's a helpful hint.  

In this case, the address in B3 is in xdc_runtime_System_abort.  Setting a HW breakpoint on that (a regular BP is not triggered, as this is in ROM?) tells me I came from           ti_sysbios_family_c64p_Exception_handler, called from "exception_return".  But a breakpoint set there is not triggered.  Trying _ti_sysbios_family_c64p_Exception_dispatch__F, which is right above it.  We hit that from a place in my code very close to where I think things are wrong.

Most importantly, I wonder if we can explain why I don't get any other indication that an exception has happened?  Or exactly what kind of exception?  That would help a lot.

Next, let's look at the assembly and see if you can help me decode it.

The offending instruction is: c393a728:   01B5A224            LDB.D1T1      *+A13[13],A3

A13 is a structure I recognize, params_PAz_as2.  A3 is a function I recognize, PAF_AS_OUT_initFrame1().  But A3 is going to be overwritten.  This appears to be loading a byte out of a structure that has no byte members.  It's not immediately obvious what exception can be caused by this.

When I run again, I sometimes get to a different place not far from that.  There the instruction is c39343b4:   00100FD8            OR.L1         0,A4,A0

Similarly, I'm not immediately able to see how this instruction can generate an exception.

Chuck Peplinski said:

In this case, the address in B3 is in xdc_runtime_System_abort.  Setting a HW breakpoint on that (a regular BP is not triggered, as this is in ROM?) tells me I came from           ti_sysbios_family_c64p_Exception_handler, called from "exception_return".  But a breakpoint set there is not triggered.  Trying _ti_sysbios_family_c64p_Exception_dispatch__F, which is right above it.  We hit that from a place in my code very close to where I think things are wrong.

Ok, this is good.  Can you check the Exception module in ROV at this point?

In newer versions of SYS/BIOS, the Exception module now prints out a register dump that you can use to get a call stack.  But, since you're on an older version, this feature isn't present (this would be one of the reasons to move to a newer BIOS).  But, you're also using BIOS in ROM so we would need to double check compatibility before doing that.

Chuck Peplinski said:

Next, let's look at the assembly and see if you can help me decode it.

The offending instruction is: c393a728:   01B5A224            LDB.D1T1      *+A13[13],A3

Can you please post "more" assembly?  It would be much more helpful to see the surrounding instructions.  A screen shot of CCS showing the C code and assembly would probably work.

Steve

Chuck,

I was discussing this with a colleague.  We think that you should get a register dump even with the older version of BIOS that you are using.  Back then, the dump was output to logs.

You should be able to see that dump if in CCS you open the raw logs view once you hit the exception:

Once you see the register dump, you can try the steps of this FAQ: http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs#4_Exception_Dump_Decoding_Using_the_CCS_Register_View

Steve

Here's a screen shot.  I've hit the exception breakpoint and used B3 to show the calling code.

I can read the IERR register to tell me that I've got an opcode and sloop exception.  

Here's the corresponding C code.  It really looks to me as if the stack is getting trashed.  This happens the third time I call go through here, so I'll just be looking more closely.  I can look at the stack.  I'll see if I can see it change horribly.

I noticed that the exception prints are at the top of the raw log.  So they are there.

Looking into http://processors.wiki.ti.com/index.php/Checking_for_Stack_Overflow, I see that B15 contains the stack pointer.  Looking at the stack as displayed, I see that it has a higher value than the stack base given in the ROV.  That seems wrong to me.  Shouldn't the stack grow into lower addresses from the base?

Chuck,

The exception probably means that that instruction is referencing a NULL or corrupted pointer.  Sounds like sometimes this instruction works, but then something happens to stomp on or corrupt a pointer that's being accessed at this instruction and that leads to the exception.

What's in A13 at this point?

Did you find the register dump in the logs?  Can you post that?

Steve

I've changed the code around a bit.  Let me try to share the latest.  This is a narrow pipe to push all of this information through, but here goes.

I've made some good progress.  Code memory is overwritten.  I'll explain the debugging chain, then you'll see my next question.

I now see that the stack starts at stack base+stack size and grows down toward zero.  That's not the problem.

Throughout this, I've equally often gotten the exception handler or else the program restarts.  This changes when I change something in the program.

I now have an additional HW break point at c_int00, as it's more likely that the program starts over (branches to c_int00) than it hits the exception code.  I have another HW BP at the exception code.  It very reliably breaks at c_int00.  B3 points into my code, the last thing to execute.  IERR says 8 (opcode exception).  EFR: 2, internal exception.  If I clear these and run again, they get reset.  So I believe I hit an opcode exception and land at c_int00.  I can't explain how.

(Frank M shared an app note about using the DA830 with DSP/BIOS in ROM.  It's "SPRAAL5.pdf".  If you can't find it and you think it helps, I can post it.)

I'm not sure how to post a further dump of the registers.  I've tried to copy the registers from CCS5.3, but no luck so far.  I just get the labels.

The attached jpeg shows the disassembly window with the instruction at B3 highlighted.  The key hint is the instruction at C3937428:  The jump address has clearly been overwritten.  That's progress.

So what overwrote it?  It looks like 2048 bytes are overwritten.  Setting a watchpoint on the location does not result in a hit.  Setting a data access count on it shows 1.  Setting a data access count on the unmodified location shows a count of zero.  

What can I conclude about who overwrote the memory from this?  DSP?  DMA?

Hi Chuck,

I noticed you marked the thread as verified answered.  Did you get past your problem?

Steve

Indeed, I am past my problem.  My last post was designed to help you improve things.  The fact that the watchpoint only worked once seems like a bug that should be fixed.    The errors in the eclipse log might matter to someone.  I don't know.  

But the watchpoint caught the code overwrite and from there I found my bug.  Thanks.

I'm about to post another question.