View previous topic :: View next topic |
Author |
Message |
LFern
Joined: 16 Mar 2011 Posts: 19 Location: Melbourne, Australia
|
PIC24FJ64GA002 Address Trap Error |
Posted: Thu Dec 15, 2011 3:32 pm |
|
|
Hi All,
I have a target application running on a PIC24FJ64GA002 micro. Used CCS PCD V4.114 as the compiler. It is handling very complex state machine while nested interrupts are enabled.
Also the same target application has been deployed in around 30 boards which I tested long hours.
I saw some boards giving me address trap error but majority is working fine.
I can assure that they all going through the same state machine doing same computation one or the other time but few of the boards keep reporting address trap errors.
I am wondering why only some of the boards reporting address trap error while others working without any problem.
Do you think its could be a silicon errata issue of the micro or component problem?
Number of address errors also different board to board for a period of time like 1 board > 1000 trap errors.
I strongly believe that there could be software bugs that is a resultant to these trap issues. but difficult to understand is why some boards only effected.
Any comments? |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Thu Dec 15, 2011 10:12 pm |
|
|
An address trap error can be a word alignment problem when you attempt to access a word variable on an odd address boundary. An intermittent problem is not unrealistic. Try adding an address trap error handler to capture the offending address. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Fri Dec 16, 2011 1:39 am |
|
|
In a first place, I would search for user code errors, particularly related to pointer operations, that can easily bring up address errors.
I observed various PCD bugs involving address errors, the latest with V4.112 and V4.121. Besides wrong data alignment, as mentioned by Andrew, also access of non-existing memory addresses, preferably due to non-initialized pointers has been the cause. Most of these have been simple cases, where the erroneous coding can be seen from the disassembly listing, occuring in the instruction before the error address, that can be determined in the address error trap rountine.
More complex cases have been caused e.g. by unpaired push/pop instructions. But these errors aren't accidental.
In your case, I would start to record error addresses with the address error traps to better understand the problem. |
|
|
|