STM32F103 Bluepill UART problem

[TadyTheFish]

Hello
I have a problem with UART communication.
I am trying to communicate with a device with 19200 8E1.
The communication does not work with the bluepill but works with Atmega 328 and 2560.
I took out my logic analyzer and I saw that there is a strange thing happening with the bluepill UART.
I attached two photos. one is showing the byte 0x68 from the device and the other 0x68 from the bluepill.
There is a differenc in the byte it is exactly 52uS longer. 1/19200 = 52uS so there is an extra bit
Serial1.begin(19200,SERIAL_8E1) should work since thy logic analyzer does not report a framing error.
Any ideas?

thank you

[ag123]

try SERIAL_8N1, if you are using libmaple core, take a look at the Hardware_Serial codes, line discipline other than 8N1 default are not (yet) implemented.it probably need to be patched up somewhere. bauds work, i can do 115200 with no issues, accordingly stm32 can do better than even that

[TadyTheFish]

I have no idea what core I'm using.. look at the photo
This is so confusing for me ..
I have this in the boards manager
https://github.com/stm32duino/BoardMana ... index.json
and from dan drown
and I have files installed from roger clark's webpage
https://github.com/rogerclarkmelbourne/ ... stallation
so it's probably Rogers core

I tried other settings. From what I have seen it seems to work. The logic analyzer has a serial decoder and I have set it for 19200 and 8E1 and the message seems ok. If I change the settings in the sketch to anything else the analyzer throws a parity error (if I leave the analyzer's settings stays the same)

[ag123]

you have probably installed both cores, if you select a board from those having a title STM32Fx Boards (STM32duino.com) are the libmaple (Roger's) cores.
if you select a board from those having a title STM32 Boards and you see boards like Nucleo, Discovery, and some Generic named boards is the official ST core.

it is good to take a little deep dive in the folders to figure out where are the core files. look in platforms.txt and boards.txt you would see matching names to the headings.
libmaple core is a community core, so the development would be more of a bazaar. but in both cases, if you make fixes, you could make a pull request in github to be evaluated so that the fixes may be added in the core.

based on when i last meddled with uart on stm32f103 libmaple core, i think the line discipline flags may be a no op. i've not checked thereafter. hence, you may like to search and review the codes for HardwareSerial to see how that works, e.g. in the codes for HardwareSerial.begin( .... ) {
note that beneath the class sources, you would also find some c headers and files for the uart functions, you could use those in conjunction e.g. to set the line discipline etc. But literally, at the end of the day setting all these things are setting the hardware registers for uart. hence, do take some time to review
RM0008 stm32 f1xx reference manual to see how those peripherals work, it would give insights along with the core code review
https://www.st.com/content/ccc/resource ... 171190.pdf

i've once contributed some fixes so that it (libmaple core f103) would check framing and parity errors, those bytes (words) are simply discarded.
the framing error checks actually works and is less sensitive to arbitrary noise. i'd guess if you figure out how to set the parity checks in the registers e.g. review the codes for functions or directly set the registers, it would check parity as well.

this is all about the libmaple core. i'm less familiar with the official core and i'd need to defer the official core to someone else to respond.

[TadyTheFish]

I forgot to post a screenshot of the boards menu. To me it seems that I'm using the official core
Those two cores are too much similar with the naming.
I will dig a little bit and see if I can figure something out.. Maybe try rodger's core.
I know I had probles with Serial.flush(); If I did a Serial.write(biff,lenght); and then flush, The could would hang and never recover

[fpiSTM]

I will check tomorrow.
Which pins you used for Serial ? The default one ?

[TadyTheFish]

PA9 and PA10 so yes the default ones. I tried using Serial2 same story. I have benn looking at the source files and I cannot find anything. It seems like a hardware thing..
There is an pause between writing bytes. The bit lenght time is ok but the pause at the end is too long. And it changes with baudrate so it is not fixed time.

[TadyTheFish]

I changed to 8N1 (it should be 8E1) and now the pauses between bytes are ok but now I get parity errors on my analyzer.

[ag123]

well because the analyzer checks parity? i'd guess you may select the relevant settings in the analyzer as 8N1 has no parity

[TadyTheFish]

Let me explain the project a little better. I'm working on a profibus slave code. This code work perfectly with arduino mega328 and 2560 and with teensy3.x but it does not work with the STM32F103. Not only I have a logic analyzer but also ProfiTrace. ProfiTrace is used for monitornig profibus messages and a lot more.
ProfiTrace is also throwing errors. If I set 8E1 (default for profibus) I get sync errors and the messages appear to be one by one byte instead of all of them in a single row. The logic analyzer show too much of a gap between two bytes ( as seen on the pictures above). The gap between two bytes from the PLC is 26.25uS@19200baud but the gap between two bytes from my slave is 78.25uS.
But if I change to 8N1 (not standard for Profibus) the gap is ok (26.25uS@19200baud) but not only the analyzer is telling me there is an parity error but also the ProfiTrace program is thelling me that ( kinda logical) but on the positive side I can see all bytes in a message in the same row and not a single byte for a row. So to me it seems there is a problem with timing when using parity

and if we do a quick calculation 1/19200 = 52uS and 78.25us-26.25us = 52us. To me it seems there is an extra "bit". The gap is consistent with baudrate. If I change the baudrate the gap time changes but it is always 1 bit long