Page 1 of 1

Trap management

PostPosted: Fri Nov 27, 2009 12:53 pm
by marc
Hi Tom,

I cannot create a new threat in the firmware section... therefore I do it here....
Below a suggestion for your error trap management in the module microcontroller.c.

When a trap is triggered a Red LED should be turned on and stay turned on even after a reboot/power off-on. In the trap error routine, there should always be a reset of the micro-controller.

At start-up, the the Red led should flash a number of time corresponding to the error type.
The user should be able to reset the Red LED with a simple procedure (eg push switch during board start-up)

So the user will know an error happens and the causes will be easier identified

PS/ I cannot upload code example in this threat...

MArc

Re: Trap management

PostPosted: Fri Nov 27, 2009 5:46 pm
by Laurent
First of all, hello to everyone here !

My approach to trap, especially during development is to keep looping in trap and flash a led to show which trap happened. Sometimes trap are very difficult to reproduce (division by 0 or oscillator fails) and it's already a good step forward to know which trap happened.


here is my trap.c
Code: Select all
#INT_ADDRERR
void addr_trap(void)
{
  while(1) {BlinkRed(3);}
}

#INT_MATHERR
void math_trap(void)
{
  while(1) {BlinkRed(4);}
}

#INT_DMAERR
void dma_trap(void)
{
  while(1) {BlinkRed(5);}
}

#INT_STACKERR
void stack_err(void)
{
  while(1) {BlinkRed(6);}
}

Re: Trap management

PostPosted: Fri Nov 27, 2009 6:47 pm
by Tom
@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 :-)

Re: Trap management

PostPosted: Tue Dec 01, 2009 1:13 pm
by marc
Tom,

...very Good idea, the "hot reboot"....it is very important to reboot as fast as possible to avoid "glitches" on the servos...

I think even on the production version, the fact that a trap error has happened should be recorded in a "EEPROM flag", and should trigger a message on the UART and on the LED for all the next reboots until a reset of the "EEPROM flag" is done.

This would help to know if error happens during flight and ease the debugging afterward... I did this on the previous version of your code and helped me to explain strange code behaviors (my USB interface feeding the board was failing in some circumstance and my code did some strange thinks afterward...this could be extrapolated to strange "behavior" of the 5V due to the brushless regulators).

CU
Marc

Re: Trap management

PostPosted: Sat Dec 05, 2009 10:47 pm
by ysroh
Hi,
this is John Roh. I've just joined the site.
In order to follow your discussion,
what are you guys working on?
Is it part of avionics code?
Is it being developed on freeRTOS?

thanks,
John.

Re: Trap management

PostPosted: Thu Mar 12, 2015 12:16 pm
by Gulu22
Hi Tom could you please enlighten me by explaining the runge kutta integration that you used? i understand that it takes weighted average, giving more weight to the values in between, but i don't understand how it is working without considering the actual "slopes" and "step size", and differential equations are not considered.

Re: Trap management

PostPosted: Fri Mar 13, 2015 6:07 pm
by Tom
There's not much to it. It's only an integratorworks better in data with noise (vibrations)

Re: Trap management

PostPosted: Sat Mar 14, 2015 4:33 pm
by fba
Gulu22

May be you should check the SimpsonĀ“s rule 1/3 itself, that works with numerical differential value not the mathematic equation.

y(now)=y(before)+(time step/6) x [sensor read (before)+ 4 x sensor read (middle)+ sensor read (now)]

sensor read is the differential value from the sensor, for example angular velocity from gyro or acceleration from accelerometer

time step = time now- time before, the time step between two measures must be rigorous the same but it is impossible reading sensor values at high frequencies or rate so by yourself :-)