2020-03-06 10:31 AM
I have just updated STM32cubeIDE from Version 1.2.0 to 1.3.0.
After uploading a previously running program, I saw that USART communication to the PC is no longer working, after IDE update. I did NOT change anything in my C-sourcecode, just recompiled and uploaded.
This effect occurs in all software, I'm using VCP as a debugging output!
I have no idea, where to search, as the C-sourcecode was not alterd at all!
As you can see in the picture below, there is something received periodically. However I'm not able anymore to set a baudrate (at HTerm) which decodes the transmitted text. I assume that the baudrate, set in USART2, is totally mismatched and anything else than 115200. Unfortunately, in this location I do not have an oscilloscope available to figure out what is reall transmitted there.
Any help is welcom - all my projects are on HALT now :grimacing_face:
BTW: I'm using a nucleo54 STM32L053R8 board.
2020-03-06 10:50 AM
Why not re-download v1.2.0 and start working again?
2020-03-06 10:52 AM
How do I downgrade? Just install the lower version?
2020-03-06 10:53 AM
2020-03-06 11:30 AM
I'm just not confortable with weekly uninstalling and re-installing the IDE, whenever something goes wrong ...
2020-03-06 11:35 AM
2020-03-06 11:42 AM
Recompiling existing code with a different IDE (and updated toolchain?) can cause clock error? Hmm hmm.
If you use ST HAL library, did the new IDE by chance updated that library to the latest?
-- pa
2020-03-06 11:57 AM
In the meantime, I completely uninstalled version 1.3.0 and re-installed the previous version 1.2.0. Can you guess what happened? Yes, THE ERROR STILL REMAINS!!!
The bitrate of the USART still is completely missconfigured, so I'm no longer able to VCP for debugging!!!
2020-03-06 12:18 PM
I have checke the USART clock, which is about 2 MHz. Unfortunately I'm not aware if that's the correct value. As what I found here, the clock should be correct.
Another strange observation: I'm transmitting around 28..30 Bytes. Each loop, HTerm receives exactly 29 Bytes, but can't detect anymore. Without an oscilloscope, I would guess the USART signal could be somehow inverted???
2020-03-06 12:44 PM
You might have better luck if your UART clock is an even multiple (of at least 16x) of the rate you want to output. Without this, you introduce some error, which the receiver may or may not be okay with.
Why would the signal be inverted? That's a strange conclusion to jump to. Stay objective.
Are you sure this was working before?