STM32F103 Bluepill UART problem

[ag123]

i took a look at rm0008 STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx andSTM32F107xx advanced Arm®-based 32-bit MCUs
https://www.st.com/content/ccc/resource ... 171190.pdf
in the uart section:
as the stm32 uart can handle 8 or 9 bits word lengths, and it can turn on / off parity
i'd like to suggest reading the USART_CR1 register (check rm0008 for the bits definition)
you could probably print out the value & check against the specs in the manual. if the values are not what you are expecting against the line discipline (e.g. 8N1) settings, it probably points to a software issue. but if the settings are correct, then possibly it may be a hardware issue

you could probably find in the header files for the base and register definition (e.g. ((USART_TypeDef *) USART1_BASE)->CR1 ). i'm not sure if it is correct, you'd need to check in the headers and test it out. and perhaps print that out to examine it

for that matter, i've occasionally patched the values in the register to my preferred settings directly, but if you diagnosed a s/w bug, do point it out here or even log a issue in the github core as well.
hope this helps

[TadyTheFish]

thank you I will give it a go but it's too low-level for me .. any pointers on hot to print out the setings?
Thank you

[ag123]

try Serial.println(value) , this should print to your usb-serial com: port monitor
simply read that register into a uint32_t (unsigned int) e.g.
uint32_t value = ((USART_TypeDef *) USART1_BASE)->CR1;
you would need to convert that to hex, binary etc manually to check against specs

[TadyTheFish]

Code: Select all

Serial1.println(((USART_TypeDef *) USART1_BASE)->CR1,HEX);

i get ...

Code: Select all

212C

[TadyTheFish]

Hmmm I'm using Serial2. Should I use

Code: Select all

.
uint32_t value = ((USART_TypeDef *) USART2_BASE)->CR2;

or is it still CR1?

[ag123]

still CR1

[ABOSTM]

Hi @TadyTheFish ,
I tested on my side and parity works fine on BluePill.
Looking at your screenshoot, everything looks normal for me:
You select 8E1, this means you want an Even parity bit, so length of a frame is:
Start+ 8 data + 1 parity + Stop
Try with 0x69 (for test purpose) instead of 0x68 thus parirty is 0 = LOW and it clearly highlights the beginning of Stop bit.
Note: my analyzer must be configured with 8E1 configuration (it is not automatic).

So for me parity is fine. Then it is true that there is a large gap between 2 bytes. I will continue my investigations.

[TadyTheFish]

My analozer also has to be configured..
Can you measure the gap between the end of the stop bit and the begining of the next start bit?

[TadyTheFish]

If you look at the first post I have posted you can see the two screenshots from the logic analyzer. One pisture is data from PLC and the other is from my slave. One has longer byte oeriod then the other. So the shortest time is from da PLC and if you know that the baudrate is 19200 then we know that one bit is 52us long. If you divide the numbers by 52us then you can see that the PLC is sending 11bits per byte (start+8bit data+parity+stop) and the slave is responfing with 12bits per byte (8E1) so to mee it seems there is an extra bit

[ABOSTM]

The extra bit is the stop which last 104us, as if Stop is 2 bits instead of one