Page 5 of 5
Re: STM32F103 Bluepill UART problem
Posted: Tue Mar 10, 2020 1:04 pm
by TadyTheFish
CR2 is 0x0
I tried Serial.write(byte); in a while loop and then Serial.flush();
And I tried Serial.write(buff,lenght); exactly the same result
Yes tomorow I can try thw libmaple core but I will need to redo the interrupt timers that I need for sync timeout and such
Re: STM32F103 Bluepill UART problem
Posted: Tue Mar 10, 2020 2:59 pm
by ag123
use an ide like vscode or eclipse
https://code.visualstudio.com/
https://github.com/stm32duino/wiki/wiki ... -extension
the key benefit is the code reference jumps, i.e. you can hop from symbol to code references e.g. functions, variables, definitions etc
it would greatly help in finding your way around codes in the core
note that there is a possibility that this is a hardware issue, like ABOSTM mentioned, there seem to be an 'extra' stop bit
the software register settings are correct
viewtopic.php?p=1459#p1459
and in addition between different releases of the same chip the more recent batches of chips may have the problem corrected
my guess is you could possibly try setting 1/2 stop bit, the catch is this applies in both direction send and receive
Code: Select all
// 00 1 stop bit (we need to zero out both bits)
((USART_TypeDef *) USART2_BASE)->CR2 &= ~ USART_CR2_STOP_Msk;
// 01 1/2 stop bit
((USART_TypeDef *) USART2_BASE)->CR2 |= 1U << 12;
Re: STM32F103 Bluepill UART problem
Posted: Tue Mar 10, 2020 3:33 pm
by TadyTheFish
Ok I just remembered something.. I hope I'm not an idiot but coul it be that I have a fake chip? I did buy the bluepill of ebay for a funny price?
I could test the software on a pyboard but that one has 405 chip and I think it is not suppored by the core
Re: STM32F103 Bluepill UART problem
Posted: Tue Mar 10, 2020 4:26 pm
by ABOSTM
note that there is a possibility that this is a hardware issue, like ABOSTM mentioned, there seem to be an 'extra' stop bit
This is not exactly what I conclude:
There is no bug from STM32, neither software nor Hardware (all registers are correct). Stop bit length is correct.
But due to stm32duino implementation there is a delay between 2 bytes (because we wait previous byte tx competition before sending the next byte). And this delay is probably synchronised with baudrate.
There is room for improvement, but it appears to be more complex than I expected. specially around management of HardwareSerial internal buffer "_tx_buffer". And there is an important risk of regression. So it is in our todo list but not a priority .
About possible fake chip ... whatever the screenshot from your logical analyzer seems correct (with a delay between bytes). What is not is that your PLC doesn't accept this valid UART frames.
Re: STM32F103 Bluepill UART problem
Posted: Tue Mar 10, 2020 5:43 pm
by ag123
a fake chip is possible, but usually a fake chip will have more problems than the uart skipping a beat
some of them failed blinky
one way is to try with a different board even for that matter a different pill (not blue pill) board e.g. from robotdyn
but like ABOSTM mention, it may after all not be fake, hard to put a finger on it really. But i'd guess it'd help to keep some better quality boards around so that you can have a benchmark to compare if you suspect something about the board or hardware
Re: STM32F103 Bluepill UART problem
Posted: Wed Mar 11, 2020 9:56 pm
by TadyTheFish
Well i tried the 1/2 stop bit and it seems the PLC is now reading the whole message at once.. So there is some success. But I still have sync errors.. I will try some more
