Finding a return address in a .lst file

[mgiuliani]

Hi, I'm the guy that made this post about how to find the return address after an address error interrupt: https://www.ccsinfo.com/forum/viewtopic.php?t=60028

Unfortunately I'm back again with a similar issue, but with a different PIC. This time I'm having address errors on a PIC24FJ1024GB610. I did the same thing as before to find the return address, and it looks like there was already something in the code for this device to do something similar. My code and that code give essentially the same result which is good.

My problem is that in my original post I was able to take whatever the return address was and CTRL + F it in the .lst file in CCS Compiler to find where that address corresponds to, but it doesn't seem to be that simple for this device. Right now my code for the address tells me 0x440000 and the other code tells me 0x43FFFE for the return address. In the .lst file the addresses only go up to five digits so I'm not really sure where to go from here to figure out what's happening.

As an example of what I have to work with right now, this is the output I have when the interrupt is hit:

ADDRESS ERROR INTERRUPT RETURN ADDRESS IS 440000

ADDRESS FAULT PC:43FFFE W0:33 W1:34 W2:FFFF W3:4C22 W4:0 W5:2 W6:0 W7:0 W8:0 W9:0 W10:4991 W11:41A0 W12:0 W13:0 W14:0 W15:7BFE DSRPAG:1 DSWPAG:1 TBLPAG:0 INTCON2:8002 INTCON4:0 CORCON:C

[newguy]

If there's no problems with the size of the variable used to hold that address overflowing, straight from your original post Ttelmah said that the 16 bit PICs will also throw the same trap if RAM at an address outside of the device's physical RAM range is attempted to be accessed.

Perhaps inspect code that deals with arrays? Pointers to RAM getting corrupted?

[Ttelmah]

Problem here is that something may be happening that the traps can't
catch.
For example. If somehow code overwrites part of the stack memory.
Perhaps a push, without a matching pop.
This won't flag an error. However if this corrupted address is 'popped'
from the stack, as a return address, and the chip then jumps to an address
that doesn't exist.
This then gives an address error.
Problem is that the error then lists the address where this happens, but
gives no clue to the actual problem with the stack...

[mgiuliani]

The problem ended up being that there were numerous places in the code where whoever wrote it was calling a debug output function that only accepts single characters as an argument by passing it whole strings. That function has no memory protection for something like that so this happened. Was only able to track it down because a little change I made suddenly caused the address error interrupt to get tripped somewhere else in the code where the handler could give me a valid return address to CTRL + F in the .lst file. I'm grateful to the moron that wrote these codebases I work on that I'm getting to debug all these horrendous memory issues so early in my career. Really drills in why memory safe programming is so important without me being the one at fault for the issues.

[Ttelmah]

Aaargh!...

If you think about it, 'passing a string', implies passing a pointer. If the
function is designed to accept a character, not surprising it was throwing
a 'wobbly', but interesting that the address was not that of this function.