| View previous topic :: View next topic |
| Author |
Message |
Chris Karis
Joined: 21 Oct 2004
Posts: 1
|
| PIC18F452 - built-in-test of WDT, interrupt dispatcher code |
 Posted: Thu Oct 21, 2004 9:27 pm |
 |
|
Two questions that are probably easy for (one or more) someone(s) out there ...
1. Is the data memory (RAM, not EEPROM) all zeroed at processor reset ? I would like to implement built-in-test of the WDT's ability to reset to the processor by looking for a unique data pattern in memory at power-on (if it;s not there, I set it up and loop waiting for the WDT to reset me) ... but it seems as if the RAM is always cleared (0's) ... didn't see this in the PIC18F452 datasheet, but perhaps it's common across the PIC18xxx family ? I implemented the same function by looking to see if the WDT tripping was the reset source (don't recall which RCON bit I'm looking at - may be POR) , but the RAM pattern gives a more robust implementation.
2. Can anyone give any guidance on replacing the interrupt dispatch code and/or an annotation of the dispatch code generated by the compiler ? I would like to get to the point where I have the bare minimum of compiler-generated code, for my IR+D project.
Thanks in advance for any help,
Chris Karis |
|
 |
Haplo
Joined: 06 Sep 2003
Posts: 659
Location: Sydney, Australia
|
|
| Posted: Thu Oct 21, 2004 9:35 pm |
|
|
To answer your second question:
| Quote: | #INT_GLOBAL
Syntax:
#int_global
Elements:
None
Purpose:
This directive causes the following function to replace the compiler interrupt dispatcher. The function is normally not required and should be used with great caution. When used, the compiler does not generate start-up code or clean-up code, and does not save the registers.
Examples:
#int_global
isr() { // Will be located at location 4
#asm
bsf isr_flag
retfie
#endasm
}
|
|
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
| Re: PIC18F452 - built-in-test of WDT, interrupt dispatcher c |
| Posted: Thu Oct 21, 2004 9:42 pm |
|
|
| Chris Karis wrote: | Two questions that are probably easy for (one or more) someone(s) out there ...
1. ... but it seems as if the RAM is always cleared (0's) ... didn't see this in the PIC18F452 datasheet, but perhaps it's common across the PIC18xxx family ? I implemented the same function by looking to see if the WDT tripping was the reset source (don't recall which RCON bit I'm looking at - may be POR) , but the RAM pattern gives a more robust implementation.
|
No this is not the correct behaviour of this processor. It does not clear memory on reset or even power on reset. I know this from first hand experience... |
|
|
Haplo
Joined: 06 Sep 2003
Posts: 659
Location: Sydney, Australia
|
| Re: PIC18F452 - built-in-test of WDT, interrupt dispatcher c |
| Posted: Thu Oct 21, 2004 10:17 pm |
|
|
| asmallri wrote: | | Chris Karis wrote: | Two questions that are probably easy for (one or more) someone(s) out there ...
1. ... but it seems as if the RAM is always cleared (0's) ... didn't see this in the PIC18F452 datasheet, but perhaps it's common across the PIC18xxx family ? I implemented the same function by looking to see if the WDT tripping was the reset source (don't recall which RCON bit I'm looking at - may be POR) , but the RAM pattern gives a more robust implementation.
|
No this is not the correct behaviour of this processor. It does not clear memory on reset or even power on reset. I know this from first hand experience... |
If you want to play it safe take a look at the #zero_ram directive. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
