CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Finding a return address in a .lst file

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
mgiuliani



Joined: 30 Mar 2023
Posts: 14

View user's profile Send private message

Finding a return address in a .lst file
PostPosted: Fri Sep 08, 2023 2:13 pm     Reply with quote

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



Joined: 24 Jun 2004
Posts: 1900

View user's profile Send private message

PostPosted: Fri Sep 08, 2023 2:27 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Sat Sep 09, 2023 1:35 am     Reply with quote

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



Joined: 30 Mar 2023
Posts: 14

View user's profile Send private message

PostPosted: Tue Sep 26, 2023 6:43 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Tue Sep 26, 2023 9:01 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group