[Top][All Lists]

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

Re: [Paparazzi-devel] Libopencm3 - STM32-F1 change interrupt priority

From: Michal Podhradsky
Subject: Re: [Paparazzi-devel] Libopencm3 - STM32-F1 change interrupt priority
Date: Thu, 22 Aug 2013 18:50:18 -0600

Hi Felix,

so I looked into it a bit more. First test with system monitor, using fixedwing with GX3 at 500Hz, and PERIODIC_FREQUENCY=500Hz.
The periodic time is an average, so it is exactly at 2ms. The max periodic cycle is however over the periodic time -> something is going on there.

Although I am not sure how to interpret the periodic_cycle. The average is 1.25ms, which represents 800Hz, but I am not aware of any loop going that fast.

I made a simple logger module to monitor system time on the autopilot. It runs at the same frequency as the periodic frequency, and sends through UART current system time  (get_sys_time_usec() from arch/stm32/mcu_periph/sys_time_arch.h). I ran couple of tests with different configurations.

Test 1: -> data1.png
Aspirin IMU, 60Hz periodic frequency. Just to get the baseline.
After first 80sec I plugged in GX3 configured to just output data @500Hz (loads of data on UART). The data from GX3 weren't processed any further though.

I calculated difference between the received timestamps and converted that to frequency. Data1 shows the result. You can see that most of the data come with frequency between 58 and 62Hz, which is +-3% around the defined periodic frequency. It is not great, but sufficient for now. Then every half second you get a timestamp at 56.6/64Hz (that is +-6% which is not acceptable precision).

At T=~80sec I plugged in GX3 and you can see that the frequency of timestamps starts to oscillate. Not much, but it definitely observable.

Test 2: -> data2.png
GX3, 60Hz periodic frequency. GX3 configured to output attitude data @125Hz which is slightly higher, but its only effect is a higher load on CPU. See data2
Most of the time the measured frequency is right 60Hz, but every 250ms the loop gets delayed (you can see the frequency drops to 58Hz and then jumps to 62Hz (probably the next loop is somehow faster).

So at lower frequencies everything works just fine.

Test3 -> data3a.png and data3b.png
GX3, 500Hz periodic frequency, GX3 @500Hz.

Now the things starts to be messy. You can see that the system frequency is all over the place, and there is some periodicity in the behaviour. The mean is still 500Hz, but the actual frequency is between 400Hz and 600Hz.

Test4 -> data4.png
Aspirin @500Hz, basically the same behaviour as with GX3.

Since the problem with timing is the same with Aspirin as with GX3, it probably wont be UART/SPI drivers/isr routines.

Any idea which other part of code could delay the loop like that?


On Wed, Aug 21, 2013 at 2:34 AM, Felix Ruess <address@hidden> wrote:
Hi Michal,

That's rather bad... I don't have any timing problems here, but then I'm not blowing heaps of data through UART...
You can also use the sys_mon module [1] to check if the timing of your main periodic is ok.
The priorities should probably be configurable.... can you make some tests if this helps or if it is something else?


Cheers, Felix

On Wed, Aug 21, 2013 at 1:02 AM, Michal Podhradsky <address@hidden> wrote:
Hi all,

I have a question about timing on Lia 1.1 (stm32f1). I recently noticed that the timing on the MCU is not solid.
I made a simple module with a periodic function which toggles an LED, ran it at PERIODIC_FREQUENCY and then plugged in a scope to see if the LED switching has a constant frequency.

I am using PERIODIC_FREQUENCY=512Hz, and the frequency moves around 30%, and occasionally bounces down to ~300Hz. If necessary, I can post video from the scope if needed.

Seems to be caused by interrupt priorities (e.g. excessive traffic on one of the UARTS can delay the main loop etc). The function nvic_set_priority() which mentioned Esden is used (master) only on a few peripherals (i2c, spi, adc, ppm), most often setting the priority to 0.

According to Cortex M3 programming manual, "If software does not configure any priorities, then all exceptions with a configurable priority have a priority of 0."
if all the configurable interrupts have the same (highest) priority, then there is no way to move the more important interrupts (e.g. UART with lots of data coming through) any higher.

The possible solution seems to be to set explicitly isr priority on each peripheral (maybe an issue for github?).

What do you think of that? Did you have similar issues with the timing?


On Mon, Apr 22, 2013 at 10:14 AM, Michal Podhradsky <address@hidden> wrote:
Hi Esden,

thanks for clarification!


On Fri, Apr 19, 2013 at 4:01 PM, Piotr Esden-Tempski <address@hidden> wrote:
Hi Michal,

I think you are mistaking the vector table slot numbers there for priorities. These are the positions of the function pointers inside the vector table. If you change those numbers then things will obviously explode.

(just for reference, here the defines get their weak functions assigned: sw/ext/libopencm3/lib/stm32/f1/vector_nvic.c, and here the vector is being put together: sw/ext/libopencm3/lib/cm3/vector.c)

IRQ priorities are set using the NVIC_IPR register, or using nvic_set_priority function.

I hope this helps.

Cheers Esden

P.S. both files nvic.h and vector_nvic.c are generated using the sw/ext/libopencm3/scripts/irq2nvic_h from sw/ext/libopencm3/include/libopencm3/stm32/f1/irq.yaml so you should not edit those files by hand.

On Apr 19, 2013, at 2:12 PM, Michal Podhradsky <address@hidden> wrote:

> Hi folks,
> I have a question about interrupt priorities for STM32F1 chip (Lia 1.1/Lisa_M 2.0).
> In sw/ext/libopencm3/include/libopencm3/stm32/f1/nvic.h are defined priorities for user interrupts. However, if I try to change the priority for example for NVIC_USART2_IRQ (let's say make it higher priority than NVIC_USART1_IRQ), the  code compiles, but then the program hangs up instantly in usart_isr interrupt routine (debugged with JTAG).
> Can the priorities be set somewhere else or is it a feature to have "hardcoded" priorities?
> Thanks
> Michal
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden

Paparazzi-devel mailing list

Paparazzi-devel mailing list

Paparazzi-devel mailing list

Attachment: 13_08_22__17_30_34_sys_mon.png
Description: PNG image

Attachment: data1.png
Description: PNG image

Attachment: data2.png
Description: PNG image

Attachment: data3a.png
Description: PNG image

Attachment: data3b.png
Description: PNG image

Attachment: data4.png
Description: PNG image

reply via email to

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