@Marc: sorry, there was a misconfiguration in the forum... now it should be ok
I would like to split this up into 2 parts:
During development:Knowing what has happened is very important! An approach like Laurent's seem to be fine. I always use the uart output, so my traps are:
- Code: Select all
#define _trapISR __attribute__((interrupt,no_auto_psv))
void _trapISR _OscillatorFail(void)
{
INTCON1bits.OSCFAIL = 0;
uart1_puts("Oscillator error!");
while(1);
}
void _trapISR _AddressError(void)
{
INTCON1bits.ADDRERR = 0;
uart1_puts("Address error!");
while(1);
}
void _trapISR _StackError(void)
{
INTCON1bits.STKERR = 0;
uart1_puts("Stack error!");
while(1);
}
void _trapISR _MathError(void)
{
INTCON1bits.MATHERR = 0;
uart1_puts("Math error!");
while(1);
}
Production code:When in flight, it is important to make sure your code keeps running, whatever happens.
An approach some avionics engineers use, is resetting the device every x seconds (or milliseconds). This requires a very short start-up time!
In my initialization, I use:
- Code: Select all
RCONBITS RCONbits_backup;
void microcontroller_init()
{
// <cut all other initialization>
RCONbits_backup = RCONbits;
RCON = 0; // we have to do this to make sure we can read RCON correctly on a (next) reset
}
int microcontroller_after_reboot()
{
return !(RCONbits_backup.EXTR || RCONbits_backup.POR); // We are in a reboot if there was no external reset
}
The traps now only execute "asm("reset");" to make sure we get a reboot!
During startup, I check "microcontroller_after_reboot()". When this is true, I try to make sure the code enters the PID loop as soon as possible (no initializing of external devices because this is useless at this point).
I'm afraid it will take a lot of experimentation to get to a good and stable trap management