2021-05-07 06:11 AM
Hello,
I try to programm a STM32F765 via USART1 (PA9/PA10), but the connection fails. I use STM32CubeProgrammer v2.7.0.
If I use USART3 instead on my target, programming works as expected.
Q: Is there a known bug, and USART1 does not work on this CPU? ( I remember that I had similar problems some years ago..). If yes where is this documented?
At the moment we are working on a design using STM32F733. We want to use the USART to program our initial bootloader.
We have no eval-board where I could test in advance that USART1 is working with that CPU. Can ST confirm that the bootloader would work with USART1 on STM32F733 ? Or should I move to another USART?
Solved! Go to Solution.
2021-06-29 02:37 AM
Hello
problem ist solved.
In the GUI version the first try to connect fails (and I see the wrong serial bytes), but if I try to connect a second time, the connection is fine.
In the command line version it seems someone added a retry (so it is a known bug) , therfore programming via command line works with one call.
2021-05-07 09:02 AM
Hello @Gunnar Bohlen ,
I raised your issue internally to CubeProgrammer team and they will come back to you with details.
Imen
2021-05-10 12:35 AM
Hello Imen Dahmen,
thank you for your quick response.
I did some further tests and found out that the connection using USART1 fails only the first time after PowerOn of the Device. When try to connect again, the second time the connection works.
When the connection fails, I get the Error "GETID command not acknowledged!", and a Chip ID of 0x00 is detected.
When using USART3, the connection is working straight after PowerOn.
Regads,
Gunnar
2021-06-29 02:21 AM
Hi @Gunnar Bohlen ,
Sorry for the delay.
I hope the problem is already solved :)
if not I can suggest you to modify the baudrates because at high UART baudrates (115200 bps) connection may fail due to software jitter.
Can you please use baudrates lower than 57600 bps and test again?
Houda
2021-06-29 02:37 AM
Hello
problem ist solved.
In the GUI version the first try to connect fails (and I see the wrong serial bytes), but if I try to connect a second time, the connection is fine.
In the command line version it seems someone added a retry (so it is a known bug) , therfore programming via command line works with one call.
2021-06-29 02:42 AM
Hi @Gunnar Bohlen ,
Glad to hear that the problem is solved :)
Houda