UART is not working properly at lower frequency

[dj_v14]

Posted on October 25, 2016 at 04:45

Hi,

I am using STM32F4xx MCU in our product and there is a GSM module connected over UART2 of MCU.Initially MCU was configured to operate at 168MHz frequency and UART2 was configured for 38400 baud rate. At that time everything works fine. But not to reduce power consumption I am trying to reduce the System Clock, and thus PCLK1/2, to 16/32MHz and UART2 at same baud rate i.e. 38400. But it is missing few data sent by the GSM and that is why the GSM is not woking. I have also tried with 9600 baud rate, but still issue persist.Do I need to change any configuration for UART? Please help.Thanks,Dhaval #stm32f4 #uart #uart #stm32f4xx

[michaelc.barton9]

Posted on October 25, 2016 at 09:38

just guessing here, but the slow peripheral clock speed (16MHz !) is causing timing errors when receiving

on Arduino, you had to calculate a timing number to give the correct Baud rate, but there could be quite high timing errors at certain baud rates which could cause data errors surely if you're wanting low power then maybe STM32L4 series would be a better choice - probably not what you're wanting to hear ! Sorry, no idea it it's pin-compatible or not without Alternatively, change the clocks so the APB1 clock is running faster - make it the same as APB2 ?

[Tesla DeLorean]

Posted on October 25, 2016 at 17:03

16 MHz should be more than adequate to support 38400 baud, you could run both APB1 and APB2 at DIV1

If you change speed on the fly, you'd need to reprogram the USART baud rate divider.

[dj_v14]

Posted on October 28, 2016 at 18:49

Hi Clive,

Thanks for your quick reply.APB1 and APB2 clock are @  16MHz and their prescalers are configured to DIV1. I also tried 9600 buad rate, but facing same issue.Following are the PLL configuration (HSE = 24MHz):PLL_M = 24PLL_N  = 128PLL_P  = 2PLL_Q  = 15AHB Prescaler = 4APB1/2 Prescaler = 1Please help me to resolve this issue.Thanks,Dhaval

[Tesla DeLorean]

Posted on October 28, 2016 at 19:39

I also tried 9600 baud rate, but facing same issue.

But is the issue with the hardware, or your buffering/processing of it?

[Tesla DeLorean]

Posted on October 28, 2016 at 19:42

The GSM modem is also likely to expect hardware flow control to be implemented when in ''data mode''

[dj_v14]

Posted on November 01, 2016 at 09:09

Hi Clive,

Thanks for you reply.I don't think it is issue with buffering/processing, as the same buffering is working fine with higher frequency. And also we have implemented UART interrupt and capturing data into the buffer in ISR. The data/characters are missing randomly from the middle of the response message, not from the beginning or from the end of the message.UART priority is set to 0x01. So it doesn't seem to be issue of interrupt priority.I tried with Hardware Flow Control enabled, RTS and CTS both, but that also didn't work.Thanks,Dhaval

[Tesla DeLorean]

Posted on November 01, 2016 at 20:24

I don't think it is issue with buffering/processing, as the same buffering is working fine with higher frequency. 

Ok, but wouldn't code that takes too long get fixed by speeding it up?You're not presenting the problem in a fashion that's going to get picked up by a validation engineer.What speeds have you run the processor and bus at? Which pass, which fail?What other interrupts are running? The USART interrupt isn't going to pre-empt itself, or anything running at the same level.