Instruction lookup on Code Composer Studio

Umang,

That address 0xFFF7E404 - isn't visible likely because it's not in the memory map.
You can see the memory map in among other places: <ccsv6>\ccs_base\emulation\gel\tms570lc43xx.gel
CCS won't read outside what's defined in the memory map if the memory map is on.

In any case you wouldn't want to read this. It's part of the memory where the peripheral registers are located.
Looks like it's between SCI and CAN peripherals. And really - it's not important what instruction is there.
Your code tried to *jump* to that address - and that's what tripped the error.

So you actually need to find the code that jumped to this address - which is where your problem will be.

Now, the problem may not be even in an instruction. It could be a stack corruption, and when you pop values off the stack into registers, the wrong value gets put into the PC. In which case you could study your code all day and not see an issue - the issue would just be in the size of stack you allocated.

Those are the things that you need to consider. The easiest way to debug this sort of crash would be with a protrace emulator.

Without one, you have to make some guesses and trial/error.

For starters, you should figure out which *mode* the processor was in when it jumped to that address. You can find this out by checking the SPSR for the abort mode.

Then let's say the processor was in user mode - hypothetically. You could look at the user-mode registers for:

- LR - if it was a BL or BLX that got you to the peripheral space, the user mode LR may be pointing towards the errant instructions.

- SP - look at where the user mode stack pointer is located. if you just popped that bad address into the PC off the stack, then the user mode stack pointer is probably pointing one word higher than a RAM location containing your bad address. You could check to see if the SP is right near the boundary of the range you allocated for it. If so then you can increase the stack size as needed to resolve the issue.

Other stuff:
-Hopefully you aren't programming flash at the time the abort occurred...
-Did you enable the instruction cache without first invalidating it's contents?

Anyway good luck - this will take a bit of time to figure out but you should be able to ...

Best Regards,
Anthony