paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] Lia 1.1. w. Aspirin 2.2 - system freeze and no kil


From: Michal Podhradsky
Subject: Re: [Paparazzi-devel] Lia 1.1. w. Aspirin 2.2 - system freeze and no kill switch
Date: Tue, 9 Apr 2013 23:04:06 -0600

Hi Sergey,

thanks for the clarification.

We started debugging on the ground with JTAG debugger (gdb) and found out that the error happens in usart_interrupt (https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/arch/stm32/mcu_periph/uart_arch.c#L85) randomly after several minutes of "flight" (meaning flight on the test bench).
We are running the GX3 at 500Hz, at 921600 baud, each packet from IMU has 67 bytes, so it is quite a lot of data.
The most likely source seems to be the Overrun Error on the UART RX line from the GX3.
Right now the code for usart_interrupt handles only two cases in the status register (USART_SR): Transmit Data reg. Empty (TXE) and Read data register Not Empty (RXNE). Thus if the Overrun Error (ORE) or any other error happens, it is not handled properly (i.e. read USART_SR and read USART_DR) so the code hangs there.

I tried to fix the problem by adding a check for ORE:
 if (((USART_CR1((u32)p->reg_addr) & USART_CR1_RXNEIE) != 0) &&
          ((USART_SR((u32)p->reg_addr) & USART_SR_ORE) != 0)) {
      usart_recv((u32)p->reg_addr);
  }

and it seems to do the job. However, it doesn't take care of all the cases either.

Do you know what kind of state machine would be the best to implement to take care of all possible USART_SR flags while keeping the code short and fast?

Thanks
M




On Sun, Apr 7, 2013 at 2:07 AM, Sergey Krukowski <address@hidden> wrote:
Hi Michal!
It's really pity if something like this happens.
Actually on STM32 the PWM generation doesn't work from sys_timer, each PWM channel is controlled by its separate timer channel, so if the main oscillator still works and clocks timers, the PWM will be further generated. Anyway, yes, there was a some kind of program error somewhere, probably hardware caused.
If you are using an external imu, the problem could be in a communication, however it's rather unlikely using a serial connection.
The first advise would be to try repeat this error on the ground to find the possible reasons for it.
Regards,
Sergey

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


reply via email to

[Prev in Thread] Current Thread [Next in Thread]