USART, 115200 not work

[zexx86]

Posted on February 09, 2012 at 17:11

Hello

I am using STM32RBT6 with my board and all is good except serial with 115200 baud rate, 57600 and lower is working correctly. I just see weird characters when receiving data. I can't get it work either with USART1 or USART2. I don't use any pull up resistor, just direct connection. I tried 50mhz gpio and different gpio input type, but nothing helped. My board contain 8mhz external crystal, cpu is running 72mhz. Even with my other board, LC Studio brand with same processor I getting same results, same with usb ttl converter and rs232. I am using ST's std library V3.4.0 with interrupts for receiving. Thanks #serial-baud-rate-speed

[emalund]

Posted on February 09, 2012 at 17:38

just direct connection. to WHAT

Whenever you have UART issues, set it up to constantly transmit 'U'' (capital U) and put a scope on tx, you should have a square wave with a frequency of exactlly half the baudrate. Erik

[Tesla DeLorean]

Posted on February 09, 2012 at 19:22

No problem achieving 115200 on an 8 MHz STM32 here.

And have demonstrated full duplex 115200 baud forwarding between two USARTS on an 72 MHz STM32.

[emalund]

Posted on February 09, 2012 at 19:29

The ''transmit 'U''' has saved me many times, last, about 10 months ago, I found out that a certainn configurattion of the ST32f1x setup code gives 1/2 the clock rate it claims while doing all calculations (e.g. setup for baudrate) based on the claimed rate.

I would never do anything to a UART case before scoping 'U's Erik

[Tesla DeLorean]

Posted on February 09, 2012 at 19:54

U (0x55) is nice because it's ASCII and transitions at every bit.

Which works till you have two stop bits, or 7 bit. Not discounting your method, but sending any repetitive bit pattern where you can see bit transitions is probably sufficient to trigger the scope and measure a bit time, or two.

[Tesla DeLorean]

Posted on February 09, 2012 at 22:03

For chuckles I cranked some of my XModem-1K code up in baud rate, and dropped the CPU to the floor.

Error/Retry free transfer of 256KB, at 460800 8N1, on a STM32 VL Discovery running at 8 MHz. >= 115200 not possible, I think I can say this myth is totally busted. You need to check out your connectivity, and choice in interface hardware. Writing to the STM32's flash memory concurrently will definitely not work at these line speeds, you'd have to do that before ACK'ing each packet. This would make YModem-G unattractive. Serial data transmission at high rate is not assured, there is no intrinsic error checking (beyond parity), and no correction, protocols need to be chosen to permit the detection of errors, and retries or correction used if appropriate.

[zexx86]

Posted on February 09, 2012 at 23:18

Thanks for help

Here is my code: http://pastebin.com/P6qu5rKK With direct connection I mean USART_RX/TX + GND to USB TTL converter or max232 (rs232), only cca 30cm wires. Tommorow I'll try 'U' test.

[Tesla DeLorean]

Posted on February 09, 2012 at 23:38

There is a race condition in the buffering, and the possibility it will reverse/shuffle blocks of characters. ie looks to be a LIFO not a FIFO

[zexx86]

Posted on February 10, 2012 at 09:57

Thanks again

I found where is a problem and succesfully resolved 🙂This made me laugh ..Just check out:static void usart_conf (unsigned short baudrate)..Sorry, thats my fault

[emalund]

Posted on February 10, 2012 at 18:19

not uncommon to try to put a quart into a pint container, usually your feet get wet 🙂

Erik