Bootloader Framing Errors - STM32L052

[Steve Krattiger]

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

[Tesla DeLorean]

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

[Tesla DeLorean]

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

 

[Steve Krattiger · Accepted solution]

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