View previous topic :: View next topic |
Author |
Message |
pfournier
Joined: 30 Sep 2003 Posts: 89
|
Interrupt causes an MCLR_FROM_RUN |
Posted: Wed Apr 29, 2015 2:41 pm |
|
|
I imported some code from an older job (16F) to an 18F87J50 and found that when I received an interrupt from one of the timers (I tried timer 0 and timer 1) or the serial port #1, it forces my processor to restart. By using restart_cause() it comes up as MCLR_FROM_RUN. When I check RCON, I found that BOR and POR bits are low. I am not using the watchdog.
I set the timer interrupts to do NOTHING. The problem only happens when I trigger the interrupt. As long as nothing happens (no time tick, so serial receive) no problem.
I'm kind of hoping someone might recognize this problem right off.
I'm going to spend the night making some REAL SIMPLE code and see if that runs.
Thanks. _________________ -Pete |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Thu Apr 30, 2015 12:06 am |
|
|
You have got interrupt handler code present?.
If you trigger an interrupt without a handler, this is what you can see. The code calls the location where the global handler should be, no interrupt code there, so it carries on, which will normally be a few bytes into the start of normal boot handling. It'll then arrive at restart_cause, with the flags all saying 'chip was running and went back to the reset location' - MCLR_FROM_RUN..... |
|
![](templates/subSilver/images/spacer.gif) |
pfournier
Joined: 30 Sep 2003 Posts: 89
|
|
Posted: Thu Apr 30, 2015 8:57 am |
|
|
Yes, I have the handlers written, but you gave me my clue!!!
The old code added space at the beginning of ROM for a bootloader (which is not put together yet) there was this huge space of 0x2800 being reserved and everything got pushed down, including the vectors. when I removed the reseved space (set by #org) my interrupts began working.
Thanks for the clue. _________________ -Pete |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Thu Apr 30, 2015 2:08 pm |
|
|
Yes, makes good sense. Effectively the handlers "weren't present". They were 'elsewhere'!.... ![Smile](images/smiles/icon_smile.gif) |
|
![](templates/subSilver/images/spacer.gif) |
pfournier
Joined: 30 Sep 2003 Posts: 89
|
|
Posted: Fri May 01, 2015 11:53 am |
|
|
I talked to the guy that originally wrote the code, and he told me you have to have the Boot code in FIRST and IT has the vectors in it! I guess there are interesting issues when using the debugger with the boot code, so we just don't use the two together. He didn't realize I did not have the boot code in. _________________ -Pete |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Fri May 01, 2015 12:24 pm |
|
|
Yes. The bootloader, contains routines to re-vector the ISR.
If you look at the example bootloader, you have this little section:
Code: |
#int_global
void isr(void) {
jump_to_isr(LOADER_END+5*(getenv("BITS_PER_INSTRUCTION")/8));
}
|
Which creates automatically two jump instructions loaded at the interrupt vectors, jumping to the corresponding code in the main program.
Programs written to use a bootloader, _require_ the bootloader to be present. |
|
![](templates/subSilver/images/spacer.gif) |
|