System Clock, Interrupts and USART data loss

[kchuva]

Posted on October 11, 2012 at 20:40

Hello,

I want to share my story about the use of the microprocessor and the problems arising from it. My system consists of a microprocessor ARM Cortex M3 STM32F103RC6 and various peripherals. I use this system to develop a variety of sensors. I use the operating system Keil RTX-RTOS. The main components of the system are USART1 and external ADC. Bluetooth module connect to USART at 115200 baud. By Bluetooth I connect to sensors and receive data via Modbus protocol. External ADC is connected to the microprocessor for SPI1 and I interrogate him with frequency 470 Hz. Processor speed - 24 MHz. The problem is a loss 1 byte of message when sensor receive data through USART. This is not always, but at random, most often when the ADC busiest. The most interesting thing that when I increase the system clock data loss almost disappears. But, it is not acceptable for the sensors, it is a disaster. What could be the reason for such behavior of the system? 1. At first I thought that the ADC interrupt stops the current execution interrupt USART. Therefore there is an overflow, set up a flag ORE, and then loss of 1 byte messages Modbus. Then I set the interrupt priority USART1_IRQ higher than the priority of ADC. It did not work. 2. I thought that interrupt handling USART just takes too long. So long, that at a certain load on the processor, the processing is not time to complete. Then I re-programmed function USART1_IRQ_Handler, that it satisfies the minimum functions (receiving data from USART register DR, notification threads ModbusService). It did not work. When SYSCLK = 72 MHz and ADC is off, data loss is not found, but so far admit. Once reduced SYSCLK once the problem starts. Any ideas?

[Tesla DeLorean]

Posted on October 11, 2012 at 21:06

Sounds like you need to do some profiling to understand where the processor is spending it's time. A low cost way of achieving that might be to signal on GPIOs the IRQs or tasks as they enter and exit.

When running at 24 MHz do you run the APB1 and APB2 at 24 MHz also? Do you turn the flash wait states and buffering off? Do you write to flash? Does your serial connection use flow control? From your description it sounds like something is blocking the serial interrupt. Have you considered using DMA?

[frankmeyer9]

Posted on October 11, 2012 at 21:15

It sounds plausible to suspect the interrupt processing under worst case conditions. Have you tried to calculate cycle and time reserves under those conditions ?

Another way is trying to catch this problematic condition. I have used GPIO signal outputs under such conditions on controllers with worse debug support. You will need a scope and set a trigger accordingly, and this may take some iterations. An IDE and debug adapter with ETM support would be more comfortable. In a commercial environment, this is definitely worth the money.

[emalund]

Posted on October 11, 2012 at 22:36

 Once reduced SYSCLK once the problem starts.

If I understand the above, everything works at 72MHz, it fails at a lower clock speed. in that case I will, with 99% certainty say ''you are violating KISS (Keep ISRs Short and Simple)'' Erik

[frankmeyer9]

Posted on October 12, 2012 at 09:09

You are not mentioning explicitly if you use DMA or not.

However, I would consider Clives suggestion seriously. If you compare the ST's peripheral units in question with that of competitors, you will notice FIFOs for UARTs and separate result registers for individual ADC channels - but not at ST. My conclusion is, ST designed this units specifically with DMA use in mind. I would make of use that, especially as it seems the uC can't keep up with your requirements at 24MHz. With the next small extension of the code requirements, it will probably drop out even more.

[kchuva]

Posted on October 12, 2012 at 11:28

APB1, APB2 are also 24MHz. I don't write to flash, I work ony with RAM. 

Yes, my serial connection use CTS-RTS flow control, but how it can influence on data loss?I can't use DMA on USART1 because I use DMA on I2C with FRAM.Today I did test: turn off thread with ADC handler, turn off Modbus Service. I wanted to test whether the loss of data in a simple transfer. I turned on the USART to receive and send by Bluetooth data packet size of 128 bytes 256 times. Loss of 2 or 3 bytes of data is stable. So, ADC interrupt is not reason of my problem.I noticed that between receiving packets occurs IDLE interrupt. Can it (IDLE frame) someways make loss data?

[kchuva]

Posted on October 13, 2012 at 09:21

Thanks a lot for all who helps me.

Last news: i think, my previous assumptions was not right, because I test my system without Bluetooth. I test UART in 485 mode with cable and results were good - no wasted bytes.Now I suppose that problem is in Bluetooth - USART tract. Used settings:

stop bit - 1

baudrate - 115200 hardware flow control - RTS_CTSWhat settings this tract can influence on loss data? May be I wrong use Bluetooth module?

[Danish1]

Posted on October 13, 2012 at 11:33

You could switch DMA from I2C to RS232.

The reason being that with the I2C link to your FRAM, the microcontroller is the master. If the microcontroller is busy, the FRAM can wait without any harm. Your problem is that (the way your code operates now) your code fails to service one UART interrupt before the another character arrives, thereby losing the first one. At 115200 baud you have less than 100 microseconds, so the UART and all higher-priority interrupts must be serviced in under that time. If you must service the UART by interrupt, you could look more closely at your interrupt-service-routines to see if there is anything that can be reduced in priority, or at least deferred to a lower-priority thread. For example does your UART receive ISR actually try to do anything with the characters it receives, or (probably better in your case) does it just put them in a circular buffer for you to deal with when the processor is less busy? Hope this helps, Danish

[frankmeyer9]

Posted on October 13, 2012 at 12:15

What settings this tract can influence on loss data? May be I wrong use Bluetooth module?

With 115200 bps, you will receive a new character about every 80us. Are you sure that your HW/SW design can guaranty that any character processing is finished before the next arrives, even if all other disturbances (other interrupts) fire at wort case rate during this time ? In general, the shorter an interrupt cycle rate is, the less efficient is the interrupt processing. Each interrupt is preceeded by a context saving, and followed by a context restoration. The closer the interrupt cycle time comes to the sum of both, the more core performance is actually wasted. I suggest to do a rough calculation of those numbers for your case. If the performance proves not sufficient in ALL cases, you might use DMA to collect several character and thus defer the requirement for immediate processing.

[Andrew Neil]

Posted on October 13, 2012 at 12:43

''my serial connection use CTS-RTS flow control, but how it can influence on data loss?''

The whole point of flow control is precisely to prevent data loss! If you are relying on the flow control to prevent data loss, and the flow control is not working - then, obviously, you will  get data loss!!