Skip to main content
Steve Krattiger
Steve Krattiger
Associate II
April 27, 2017
Solved

Bootloader Framing Errors - STM32L052

  • April 27, 2017
  • 3 replies
  • 1521 views
Posted on April 28, 2017 at 01:42

Hi, 

I'm writing an application on an STM32L052 that uses the UART (115200-N81), and I need to use the Bootloader for code upgrades.   

If run the Bootloader using the BOOT0 pin, the UART initializes fine and I can upload code at any baud.   However if I jump to the Bootloader code from my application, the Bootloader isn't initializing the UART correctly, and I get framing-errors transmitted out from the CPU.   

From the scope traces (good and bad are attached), I can see that at any baud rate (115200-E81 shown), the Tx signal is switched to '0' between each byte instead of staying high, this causes a framing error.   It almost seems as though the stop-bit is missing or inverted.   

I'm guessing that in my application's use of the serial port, something is left in a register somewhere that doesn't get initialized in the Bootloader code.   Since I cannot modify the Bootloader code, I need to find the errant register that causes a missed stop-bit, or causes this framing error.   

Anyone run into this before???    

- SteveK

#stm32l052 #bootloader #framing-error #uart-tx
This topic has been closed for replies.
Best answer by Steve Krattiger
Posted on April 29, 2017 at 00:34

So, this issue has been fixed.   The first suggestion cleared things up.

Prior to jumping to the Bootloader, I had called HAL_UART_MspDeInit(&huart1); and all the other peripheral de-init functions, disabled and cleared all ints per AN2606.   However the de-init functions do not set the registers back to the bootup state.

With some further trials, i've narrowed it down to the USART1->CR1 register.   The DeInit function leaves the 'UE' bit enabled.   If you jump into the bootloader with the UART enabled, it does not initialize correctly.

And, I found that if you run the DeInit function, you cannot overwrite some of the USART1 registers to '0'.   Instead, I no longer call the DeInit function for the UART, but just zero out the bits with direct register writes.    It's working good now.

Thanks!

-SteveK

3 replies

Tesla DeLorean
Tesla DeLorean
Guru
April 28, 2017
Posted on April 28, 2017 at 03:44

Might start by zeroing out the TIM and USART registers.

More practically, add code in your FLASH Reset_Handler to recognize a magic value, remap the ROM back at zero and jump into it, and then reset the part. The chip is in reset conditions, and you're in the System Loader

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
Tesla DeLorean
Tesla DeLorean
Guru
April 28, 2017
Posted on April 28, 2017 at 03:50

My other post is stuck in moderation.

You'll need to tune this to L0 specific memory and registers

https://community.st.com/0D70X000006SKsSSAW

 
Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
Steve Krattiger
Steve KrattigerAuthorBest answer
Associate II
April 28, 2017
Posted on April 29, 2017 at 00:34

So, this issue has been fixed.   The first suggestion cleared things up.

Prior to jumping to the Bootloader, I had called HAL_UART_MspDeInit(&huart1); and all the other peripheral de-init functions, disabled and cleared all ints per AN2606.   However the de-init functions do not set the registers back to the bootup state.

With some further trials, i've narrowed it down to the USART1->CR1 register.   The DeInit function leaves the 'UE' bit enabled.   If you jump into the bootloader with the UART enabled, it does not initialize correctly.

And, I found that if you run the DeInit function, you cannot overwrite some of the USART1 registers to '0'.   Instead, I no longer call the DeInit function for the UART, but just zero out the bits with direct register writes.    It's working good now.

Thanks!

-SteveK

Terms & ConditionsAccessibility statement