STM32F103 Bluepill UART problem

[TadyTheFish]

Yes that was my asumption n also.. If I use 8N1 the byte lenght is ok but ofcourse that meanso no parity bit and the PLC is not happy

[ag123]

the stop bit settings is in the CR2 register, you can use basically the same method to read CR2 and print that out.
similarly keep RM0008 handy and check the specs in there against the values you found
stm32 has quite a few stop bits settings, there are quite a few other settings which may not related to async but they are in CR2 as well
parity and word length is in CR1, if you found it different from what you expect, you can try setting it directly in the registers
but if the HardwareSerial api works correctly, it should give the appropriate settings based on your selections.

but imho having a gap between 2 bytes shouldn't matter, isn't it? the notion is that uart would check the framing start stop bits to determine that the byte is received. parity should add that additional bit before the stop bit

[TadyTheFish]

It seems that ProfiTrace disagrees. Bytes are shown one for each row instead of the whole message in one row.. This is the only explanation why I have a Profibus error led on the PLC.. I checked all the timings and everything and this is the only explanation left.. I really don't know my way around these registers but I have nothing else left to try. The core files are so comolex and one is dependent on the other so I get quickly lost.. But I wil take another whack at it.
If I can't get it to work I'm stuck at atmegas that are so slow. I can max 45.45k baud. Only teensy worked to 1.5M maybe with tweaking I could make it run at 3M but teensy is a pain in the butt to program when it is an embedded project.

[ABOSTM]

As I said, parity if working fine, and I checked register everything is good.
Then about Stop which is lager than expected:
Register are properly configured, but the gap is due to the current implementation of write operation.
Characters are send 1 by 1 on UART. It means we wait for 1st Byte completion (IT call back), then we send 2nd Byte. This takes time and so it is normal to have a gap between Stop and Start.
And as said ag123 it should not matter. you are allowed to wait between 2 Bytes.

So there is no bug.
Nevertheless, I will think about improvement to send whole buffer in 1 shot. This should increase throughput a little bit.

[TadyTheFish]

Ok thank you for your time for looking into this. I understand that it takes time to put a new byte to the buffer but the thing that bothers me is that the time changes exactly as the baudrate does. It is always 1bit long and I don't understand how the CPU can put the new byte in to the buffer faster if you increase the baudrate but the CPU frequency stays the same. Tomorow I will record the mega328 message. It does it in the same way. It puts a byte into the buffer and the interrupt flushes it out.

[BennehBoy]

Ok thank you for your time for looking into this. I understand that it takes time to put a new byte to the buffer but the thing that bothers me is that the time changes exactly as the baudrate does. It is always 1bit long and I don't understand how the CPU can put the new byte in to the buffer faster if you increase the baudrate but the CPU frequency stays the same. Tomorow I will record the mega328 message. It does it in the same way. It puts a byte into the buffer and the interrupt flushes it out.

It's because the interrupt timer is at the desired baud...

[ag123]

So there is no bug.
Nevertheless, I will think about improvement to send whole buffer in 1 shot. This should increase throughput a little bit.

i think buffer send would improve things quite a bit. just that we can't help possibly buggy the other end uart implementations e.g.. between 2 buffers, there may be a waiting period, the other end should not treat that as an error. the other thing is some developers may not be quite prepared for buffer send as it needs to spin lock ('hang') for a short time to see that the whole buffer is transmitted. but i think buffer send is a nice thing to have. possibly a different function to call. i think dma is possible too, just that it seem a bit extreme for uart to do dma. but with dma we can possibly goto 1mbps kind of speeds

[ABOSTM]

I don't understand how the CPU can put the new byte in to the buffer faster

From hardware point of view, it is possible to prepare next byte while harware is currently sending the previous one, there is a mechanism of shadow/shift register.

[TadyTheFish]

I did some digging

Code: Select all

Serial2.begin(19200,SERIAL_8E1);

Code: Select all

Serial.println(((USART_TypeDef *) USART2_BASE)->CR1,BIN);

gives me

Code: Select all

 11010100101100

The data sheet says bit12 of the CR1 register is the word length
0 = 8bits
1= 9 bits

So looking at the output it seems it is set to 9 bit word length

But if I set the register with

Code: Select all

((USART_TypeDef *) USART2_BASE)->CR1 = 0b10010100101100;

The gap between bytes is OK and ProfiTrace correctly frames the message BUT ProfiTrace and logic analyser starts complaining about parity error
Am I missing something or do I not understand the registers correctly?

Thank you

[ABOSTM]

It is true that register is configured with CR1_M = 1,
which means 1 Start bit, 9 Data bits, n Stop bit.
But among the 9 bits there is parity.
There is a clear table in ...\system\Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_hal_uart.c

Code: Select all

    +-------------------------------------------------------------+
    |   M bit |  PCE bit  |            UART frame                 |
    |---------------------|---------------------------------------|
    |    0    |    0      |    | SB | 8 bit data | STB |          |
    |---------|-----------|---------------------------------------|
    |    0    |    1      |    | SB | 7 bit data | PB | STB |     |
    |---------|-----------|---------------------------------------|
    |    1    |    0      |    | SB | 9 bit data | STB |          |
    |---------|-----------|---------------------------------------|
    |    1    |    1      |    | SB | 8 bit data | PB | STB |     |
    +-------------------------------------------------------------+