Trap management

Here is the place for all your dsPic or autopilot questions.

Moderator: lukasz

Trap management

Postby marc » Fri Nov 27, 2009 12:53 pm

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
marc
 
Posts: 21
Joined: Wed Nov 25, 2009 3:28 pm

Re: Trap management

Postby Laurent » Fri Nov 27, 2009 5:46 pm

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);}
}
Laurent
 
Posts: 5
Joined: Fri Nov 27, 2009 5:23 pm

Re: Trap management

Postby Tom » Fri Nov 27, 2009 6:47 pm

@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 :-)
User avatar
Tom
Site Admin
 
Posts: 1016
Joined: Fri Nov 13, 2009 6:27 pm
Location: Belgium

Re: Trap management

Postby marc » Tue Dec 01, 2009 1:13 pm

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
marc
 
Posts: 21
Joined: Wed Nov 25, 2009 3:28 pm

Re: Trap management

Postby ysroh » Sat Dec 05, 2009 10:47 pm

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.
ysroh
 
Posts: 3
Joined: Sat Dec 05, 2009 10:31 pm

Re: Trap management

Postby Gulu22 » Thu Mar 12, 2015 12:16 pm

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.
kaleem
Gulu22
 
Posts: 1
Joined: Thu Mar 12, 2015 12:11 pm

Re: Trap management

Postby Tom » Fri Mar 13, 2015 6:07 pm

There's not much to it. It's only an integratorworks better in data with noise (vibrations)
User avatar
Tom
Site Admin
 
Posts: 1016
Joined: Fri Nov 13, 2009 6:27 pm
Location: Belgium

Re: Trap management

Postby fba » Sat Mar 14, 2015 4:33 pm

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 :-)
Francisco
User avatar
fba
 
Posts: 47
Joined: Sun Jan 06, 2013 9:13 pm
Location: Spain


Return to Firmware

Who is online

Users browsing this forum: No registered users and 1 guest

cron