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

SOLVED: Tracking Down the Return Address for an Interrupt

 
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

SOLVED: Tracking Down the Return Address for an Interrupt
PostPosted: Tue Apr 11, 2023 7:08 am     Reply with quote

CCS Compiler Version 5.075

I am working with a unit that has a PIC24FJ256GA606 chip, trying to find which part of its firmware is raising a address error interrupt (#INT_ADDRERR). I placed the assembly code from this post into the handler for the interrupt in my firmware: https://www.ccsinfo.com/forum/viewtopic.php?t=36479.

That assembly code gives an address of 4983809 or 0x4C0C01 every time, so it seems it's always the same part of the code and this is a replicable failure. I can't or don't know how to correlate that to anything in program memory or firmware code for the device.

I've been using an ICD-U80 debugger to halt the code when this interrupt occurs and have been adding debugging outputs to narrow down as much as I can but it's taking a long time. This is my first time debugging something like this so if anyone could give me some recommendations on how to find the root cause it would be greatly appreciated.


Last edited by mgiuliani on Wed Apr 12, 2023 11:10 am; edited 2 times in total
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Apr 11, 2023 7:10 am     Reply with quote

hmm... have you printed the listing for that memory location ??
mgiuliani



Joined: 30 Mar 2023
Posts: 14

View user's profile Send private message

PostPosted: Tue Apr 11, 2023 7:23 am     Reply with quote

temtronic wrote:
hmm... have you printed the listing for that memory location ??


Forgive my slowness but could you explain what you mean by this? If it's relevant at all, the debugging tabs for RAM and ROM are populated and I have the .lst file and other output files for the code.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Apr 11, 2023 10:22 am     Reply with quote

If you do search in the forum, you will find that the offset that has to
be used, changed with the V5 compilers. They save a couple of bytes
more. If you are using the offset from the post you point to, this will
not be giving the correct address with the newer compiler.

Use the version here (with the interrupt declared as FAST), which avoids
this being a problem:

[url]
https://www.ccsinfo.com/forum/viewtopic.php?t=57977&highlight=intaddrerr
[/url]

On the standard version you point to, you have to change the sub to
38, instead of 36 on the V5 compilers. This is why the value you are
getting does not make any sense...

Also remember, this is the return address, so an instruction after
where the problem applies.

The classic thing that would cause this error, is using a pointer to
an int8 value, incrementing it (so it now points to an odd address),
and then using this to read or write a 16bit value, Word values can
only be accessed on even addresses, The compiler will not itself do
this, but if you are using pointers to int8 values, you can trigger this.
Look at all the code you have that uses pointers.
mgiuliani



Joined: 30 Mar 2023
Posts: 14

View user's profile Send private message

PostPosted: Wed Apr 12, 2023 11:08 am     Reply with quote

Ttelmah wrote:
If you do search in the forum, you will find that the offset that has to
be used, changed with the V5 compilers. They save a couple of bytes
more. If you are using the offset from the post you point to, this will
not be giving the correct address with the newer compiler.

Use the version here (with the interrupt declared as FAST), which avoids
this being a problem:

[url]
https://www.ccsinfo.com/forum/viewtopic.php?t=57977&highlight=intaddrerr
[/url]

On the standard version you point to, you have to change the sub to
38, instead of 36 on the V5 compilers. This is why the value you are
getting does not make any sense...

Also remember, this is the return address, so an instruction after
where the problem applies.

The classic thing that would cause this error, is using a pointer to
an int8 value, incrementing it (so it now points to an odd address),
and then using this to read or write a 16bit value, Word values can
only be accessed on even addresses, The compiler will not itself do
this, but if you are using pointers to int8 values, you can trigger this.
Look at all the code you have that uses pointers.


This worked perfectly and I was able to narrow down exactly where in the mess of a code base I'm working with this interrupt is happening. Thanks!
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Apr 12, 2023 11:36 pm     Reply with quote

I remembered hitting that problem a few years ago, when the V5
compiler started. Posted the offset fix at the time, and then a little
later the fast interrupt solution was posted, so felt this was the one
to point you to.
Glad I hit it. Very Happy
Any hints as to what is causing the problem?. The pointer offset one
is the commonest.
mgiuliani



Joined: 30 Mar 2023
Posts: 14

View user's profile Send private message

PostPosted: Thu Apr 13, 2023 6:49 am     Reply with quote

Ttelmah wrote:
I remembered hitting that problem a few years ago, when the V5
compiler started. Posted the offset fix at the time, and then a little
later the fast interrupt solution was posted, so felt this was the one
to point you to.
Glad I hit it. Very Happy
Any hints as to what is causing the problem?. The pointer offset one
is the commonest.


We have a variable in our code that is storing the length of a string as we read it in over UART. After we read the full string in we subtract 4 from the total length. If a corrupted string came through the length could be under 4, so subtracting 4 makes it overflow to 65535. We use that overflown length to determine how many times we need to iterate a for loop, so when the iteration counter in the for loop ticks to a certain number (always 31446 in this case) it raises the address error interrupt. The guy that wrote this didn't put a single check in for rejecting corrupted or improperly formatted strings or any memory safety checks. This is happening in a very important function too. Don't outsource your firmware if you can help it friends.
jeremiah



Joined: 20 Jul 2010
Posts: 1314

View user's profile Send private message

PostPosted: Thu Apr 13, 2023 8:19 am     Reply with quote

Ttelmah wrote:
If you do search in the forum, you will find that the offset that has to
be used, changed with the V5 compilers. They save a couple of bytes
more. If you are using the offset from the post you point to, this will
not be giving the correct address with the newer compiler.

Use the version here (with the interrupt declared as FAST), which avoids
this being a problem:

[url]
https://www.ccsinfo.com/forum/viewtopic.php?t=57977&highlight=intaddrerr
[/url]

On the standard version you point to, you have to change the sub to
38, instead of 36 on the V5 compilers. This is why the value you are
getting does not make any sense...

Also remember, this is the return address, so an instruction after
where the problem applies.

The classic thing that would cause this error, is using a pointer to
an int8 value, incrementing it (so it now points to an odd address),
and then using this to read or write a 16bit value, Word values can
only be accessed on even addresses, The compiler will not itself do
this, but if you are using pointers to int8 values, you can trigger this.
Look at all the code you have that uses pointers.


It might be worth it to post that in the best of forum for later use. Easier to find and while not super common, it might be common enough of a problem to consider it.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Apr 13, 2023 10:20 am     Reply with quote

OK. I've put a link there. Smile
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Apr 17, 2023 1:24 am     Reply with quote

That is quite a 'fun' one to find.
The PIC24's, do give an address error, if you try to read/write to a page
where RAM is not implemented, so explains what was happening. Have been
plenty of warnings here in the past, that you must 'bounds check' when
dealing with array indices. This is a real reminder of the importance of this...
Well done in tracking it down.
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