STM32F103: Can a timer can interfere with uart?

Question

I have a simple program, which receives data from UART interface and drives a WS2812b led strip. So, I'm using USART3 to receive data (in IRQ mode) and T3C2 (timer 3, channel 2) to drive LEDs. Here is the code:

https://hastebin.com/rucumovero.cpp

If I use the uart interface without enabling a timer, everything works just perfect, but when I enable the timer I start losing data. For example, here the log if I send 5 similar 32 byte packets [0x41..0x60]

read 29 byte(s): 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 
read 29 byte(s): 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 60 
read 28 byte(s): 41 42 43 44 45 46 47 48 49 4A 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5D 5E 5F 60 
read 29 byte(s): 41 42 43 44 45 46 47 48 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 5A 5B 5C 5D 5E 5F 60

every time 3~4 bytes are lost.

I tried to use different baud rate, different usart port - the result is the same. The timer interval is set in line 142:

timer_set_period(TIM3, WSP);

where

#define TICK_NS (1000/72)
#define WSP (1300 / TICK_NS)

If I comment out this line, the problem will disappear, but, of course, I won't be able to drive LEDs without it.

So, it looks like I can't drive WS2812b leds and receive data from UART at the same time. Is it supposed to behave like this? Any idea how can I fix it?

Answer 1

Looking at this

#define TICK_NS (1000/72)
#define WSP (1300 / TICK_NS)

your timer takes about 100 steps (if i got it right from the specs) and then runs whatever routine you told it to. I couldn't clearly see how much time it takes for your program to make one step, but it seems as if your timer routine should run very often (couple 1000 times per second or more).

Now if your uart routine works as expected without the timer, but loses data when you introduce it, it strongly suggests that the timer disrupts your serial communication.

This could be because:

1. your timer routine runs to often
2. the timer routine is too long
3. the timer interrupt has a higher priority than the uart interrupt.

Or maybe its all three put together.

Possible solutions:

1. An STM32 has something called the NVIC (Nested Vector Interrupt Controller), which you could use to change the the interrupt-priorities.

2. When you use two or more interrupts you have to consider that they may run at nearly the same time(this happens more often when both interrupts run at similar frequencies), and one routine may loose information because of this (especially with uart). So you have to think of a way to handle this explicit case -> locking mechanism or altering the priorities.

3. The longer your routine takes, the higher is the chance that you enter the case described in point two. It's usually good practise to make interrupt routines as short as possible, and never ever use delays or loops inside an interrupt.

4. Consider if there is a way to run your timer routine considerably less often. This way you at least minimize the chance of data loss, but to completly rule it out, you will have to do the things described in point 1-3.

Answer 2

I think the problem is the time spent by timer interrupt routine and you have not configured the priorities. Either make the timer routine efficient enough, or make a DMA buffer for the UART, or raise the priority (lower priority number) of the uart interrupt (which may mean visual glitches on the display, in this case make critical parts of timer code non-interruptable and see if it is sufficient to help the UART)

Also you can unify all of them in one timer interrupt routine. You either make the timer frequency fast enough for the UART without DMA buffer and poll it & run the normal timer code with a lower frequency, or, make a DMA buffer and run the timer as slow as the normal code needs and poll the UART buffer. This makes things more deterministic in contrast of polling in the process mode.