STM32L151 bootloader autobaud issues

[peterlauner9159]

Posted on December 17, 2015 at 10:06

Hi,

We are working on a design utilizing the STM32L151 MCU, which is to be programmed over a UART link using the internal bootloader. Selected baudrate for programming is 115200 (with even parity).The issue we are having is that the baudrate on the UART link from the MCU varies a lot from one reset to the next. We understand that the MCU has an internal autobaud algorithm, but the output from this algorithm seems inaccurate. Measuring the baudrate of the initial 0x7F byte sent as ''init'' to the MCU we measure 115741 baud (0.47% off ideal 115200) and this baudrate is exactly the same on each MCU reset. The resulting baudrate of the ''ack'' command back from the MCU (0x79) varies between 114750 and 121950 baud (~6%) , this variation is larger than what our receiving UART can handle which results in communication errors.Is there anything that can be done to increase the precision of the autobaud algorithm in the bootloader? Edge-rates of the UART signal to the MCU is around 200ns, which seems to be fast enough to give a reasonable edge detection in the autobaud detection.When the STM32 MCU is programmed with the real application the baudrate is programmed to 115200 in code, which results in a measured baudrate of 115980 baud. This confirms that internal clocks etc are working as expected.Thanks

[Tesla DeLorean]

Posted on December 17, 2015 at 16:35

How long do you give the part to settle after reset?

The STM32's typically use a timer to quantify the 0x7F data pattern vs the internal clock, it's not actually trying to receive that data. Likely Input Capture, or PWM Input mode. Not sure there is a more ''accurate'' method.Does the behaviour change if you drive the pin less aggressively, or use a series resistor?If this continues to be problematic, consider using the loader at lower speeds to download your own loader into RAM, and have that take control with external crystals and known transfer rates.

[peterlauner9159]

Posted on December 17, 2015 at 22:32We typically give the device around a second or so after reset before sending the initial 0x7F pattern, this is achieved by sending the reset command to the bootloader from the flash application and measuring the baudrate of the response. A reset will take place during each iteration. This is done manually, so there is ''plenty'' of time.We have tried driving the UART to the STM32 with different slew-rate and different models of UART transceivers, but the result does not change.Regarding a more accurate method, what I expected was that the STM32 would measure the incoming baudrate of the incoming 0x7F pattern and then select the closest standard baudrate when setting up the USART. For example, if the measured baudrate was 119.76 kbps the USART would be programmed to 115.2kbps. That does not seem to be the case, the USART is actually programmed by the bootloader to whatever was seen on the input 0x7F pattern. Locking to a standard rate means that the detection only needs to be accurate enough to notice the difference between 38400, 57600 and 115200 etc...We will drop the rate to 38400 or 57600, which requires a bit of work actually on the other side. If that also fails, we will consider a permanent bootloader in flash.

[otmar]

Hi

I have the same problem

My STM32L151 anwers always to the Flash Loader Demonstrator with the same (wrong) baudrate.

So there is always a "unrecognized device" error.

I tested every available baudrate -always the same...

Next I have tested with hyperterminal and send the 7F to the uC - and the correct 0x79 was replied by the uC. ????

When i check the levels of the Rx and Tx lines, there is a difference if i use the hyperterminal (both lines are high in idle) or the Demonstrator (Tx is high and Rx is low) - why this?

Next i tested with another project where a STM32F103 is used. There the Flash Loader Demo works fine - and the levels of the RS232 are like this:

In idle the Rx line is low, the Tx line is high, when i start bootloader mode - the Tx line goes low.

Have you the same situation?

Otmar

[Tesla DeLorean]

These are posts from 3+ years ago.

9600 8E1 should work on all platforms. If should be relatively robust, but is a one-shot deal, and will be sensitive to even very brief glitches/pulses.

Determine the loader version you are working with.

Check what pins the loader is monitoring, it usually looks for multiple pins. Check the errata.

Discuss with local FAE or support resources out of the local sales office. Ideally work with someone who can work directly with your hardware, and review the schematic.

The performance on the STM32F4-DISCO is problematic due to a large capacitor on one of the USART1 pins.

[otmar]

Hi Clive

Oops - Sorry i haven't noticed this, that this posts are really, really old...

...and thanks for your reply.

my Flash Loader Demo ist v2.8.0 - the latest (i hope) i've found on the website.

did you mean the errata of the L151?

Probably you've right with the Pins. I have tested the bootloader on two different boards (always the same controller)

and there is the same problem on each board.

I dont recognize why the L151 answers, connected to a Hyperterminal , which the correct baudrate ...hhmm..

Do you know if "my" levels, in the idle state, of the Rx line (low) and Tx Line (high) are correct?

Perhaps make it sense to buy an Nucleo 64 -STM32 L152 Board to verify my Flash download via UART?

Is this possible on the eval board?

Thanx for your patience Clive

Otmar