STM32f407 dma->uart transfer stops after some time

[MOtto.1]

Hi, i have a certain problem.

I have an application which continuously reads out data from sensors. Each sensor read will be triggered by me by using a dma-uart transaction. On the receiving side i have a uart-dma in cyclic mode which fills up the buffer and gives me the wr/rd pointer to the incomming bytes. Currently i got 2 sensors each running on it's own task, so there is also a RTOS involved. All sensors are on a RS485-Bus in halfduplex mode, so i have to toggle the data-transmit or receive pin of the tranceiver by software. For that i'm waitng on the uart TC-Flag to occure inside an ISR to switch back to receive.

Now there is a problem. At first everything works fine, but after several hours i see that the transceiver is still on transmitting didn't went back to receive, so the whole Bus is blocked. Task is still running. 

Could it be that interrupts are delayed that much (RTOS or i disable interrupts in my debug printfs) or even missed so that my uartTC-interrupt is enabled after uartTC is allready set?

I have allready changed the code in the way i am not enabling the uartTC interrupt in the dma-ISR. And somemore.

I want to tackle the issue and get into the situation to switch it on and off to confirm my changes are valid.  

 

Thanks

[TDK]

Probably this is RTOS related. Perhaps a thread goes rogue, or you run out of memory, or some other condition. Attach a debugger when it's in the faulty condition and explore the state of the system, threads, and peripheral registers.

If it's waiting for a TC flag but didn't get one yet, exploring the DMA registers would likely tell you why.

[MOtto.1]

Hi, debugging should be little bit hard for me. It really happens seldom it's not hours but days it works well. RTOS, could be but none of my task are stalled and i had the chance to not normally, using the dma->uart transfer, but polling the uart to send some data on the system with faulty condition. As soon it switches back to normal transfer it remains setting the transceiver transmitting and blocks the bus. 

I'm not using fifo, so could be a bandwidth issue? Or, because i enable interrupts inside another interrupt (changed already) could be uart TC already set while interrupt enable set later? 

 

[TDK]

DMA bandwidth far exceeds that of the UART. Unlikely to be the issue.

It's probably a program logic bug. I tried to look at your code but a lot of it is missing. Enabling interrupts inside interrupts can be okay if done right.

Having two different threads control the same bus can be problematic. I don't know if the relevant RTOS locks are working properly. Certainly the locks in HAL are insufficient for this task. The hardware has the necessary capabilities to handle this properly in the form of LDREX/STREX instructions, but I don't know if those are being used.

How are you ensuring only one thread is controlling the bus at a given time?

[MOtto.1]

Which bus do you mean, RS485 or the AHB bus? For the RS485 there are two different transceiver on board. I only use locks to prevent two concurrent reads for data. Sometimes i disable all interrupts masked by freertos.  

[TDK]

RS-485 bus. I was referring to this statement:

> All sensors are on a RS485-Bus in halfduplex mode, so i have to toggle the data-transmit or receive pin of the tranceiver by software.

If both sensors are on the same RS-485 bus, you will need to ensure only one is active at a time.

[MOtto.1]

Could it be that there is a chance, that two task of mine are negatively have there impact. For instance see attachment.

 

I have set dma and uart interrupts on the same prio. But from the timing point and NVIC prio the dma interrupts should come first. Is there a chance that the DMA_SxNDTR register reaches zero but the EN Bit is still high?

[AScha.3]

>All sensors are on a RS485-Bus in halfduplex mode, so i have to toggle the data-transmit or receive pin of the tranceiver by software.

- i dont understand this. rs485 driver switching rx/tx automatic , the uart needs to be in 485 mode, then it switching the /en line when sending, all other time its on receiving mode. this is how rs485 works...

+

interrupt priority is important - if not shure, just "play" a little, set the more important one level higher, and test.

is faster than asking and think about, what happen if same priority level.

[MOtto.1]

Hi, unfortunately i'm unseeing the UART4/5 and those do not have any flow control mechanism or pins. So i have to toggle them accordingly. Yes i'm varying the interrupts.