Problem with the STM32 bootloader's UART protocol
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-11-23 1:10 AM
I have a custom board based on STM32F412VE that communicates with the PC via the UART1 (pin PA9 and PA10 with 100K pullup). I have problems communicating with the bootloader. Here is an oscilloscope screenshot:
As you can see PC send 0x7F and after a while bootloader respond with ACK (0x79). I must assume that UART is good and at this point the bootloader is ready to receive commands. The PC then sends the GET (0x00+0xFF) command but immediately after the first byte the bootloader responds with NACK (0x1F). I cannot figure out why. Please note that the Flash Loader Demonstrator does not work either.
best RegardsMax#stm32-uart-bootloader #stm32f412- Labels:
-
Bootloader
-
STM32F4 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-11-23 2:17 AM
... communicates with the PC via the UART1 ...
Is this the ST-Link Utility on PC side, or your own tool ?
If the latter, I suggest to check with the ST-Link tool or the Flash Loader Demonstrator, and compare the behavior.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-11-23 3:46 AM
ST-Link Utility only communicate through jtag/swd. The
Flash Loader Demonstrator also has the same problem.
best regards
Max
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-11-23 4:39 AM
Try lower baudrate rate. Make sure even parity.
Check voltage and caps on VCAP pins.
Check bit timing on responses.
Down load USART test code via debugger.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-01-15 4:22 AM
I just solved this problem by adding very short delay between command bytes, for example 0x00 delay 0xFF. I will use one STM32 MCU to program other devices. By the way.... it doesn't work for me with even parity bit somehow, only with no parity bits.
