 |
 |
| View previous topic :: View next topic |
| Author |
Message |
mgiuliani
Joined: 30 Mar 2023
Posts: 17
|
| SOLVED: Tracking Down the Return Address for an Interrupt |
 Posted: Tue Apr 11, 2023 7:08 am |
 |
|
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: 9225
Location: Greensville,Ontario
|
|
| Posted: Tue Apr 11, 2023 7:10 am |
|
|
| hmm... have you printed the listing for that memory location ?? |
|
|
mgiuliani
Joined: 30 Mar 2023
Posts: 17
|
|
| Posted: Tue Apr 11, 2023 7:23 am |
|
|
| 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: 19504
|
|
| Posted: Tue Apr 11, 2023 10:22 am |
|
|
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: 17
|
|
| Posted: Wed Apr 12, 2023 11:08 am |
|
|
| 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: 19504
|
|
| Posted: Wed Apr 12, 2023 11:36 pm |
|
|
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. 
Any hints as to what is causing the problem?. The pointer offset one
is the commonest. |
|
|
mgiuliani
Joined: 30 Mar 2023
Posts: 17
|
|
| Posted: Thu Apr 13, 2023 6:49 am |
|
|
| 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.
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: 1346
|
|
| Posted: Thu Apr 13, 2023 8:19 am |
|
|
| 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: 19504
|
|
| Posted: Thu Apr 13, 2023 10:20 am |
|
|
OK. I've put a link there.  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Mon Apr 17, 2023 1:24 am |
|
|
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. |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
