STM32F030 bootloader reliability over rated temperature range?

[pmoore]

Posted on July 15, 2015 at 01:11

I'm thinking about using a STM32F030 in a slave application where a master may need to reprogram the STM32F030 via the bootloader in the field.  I have had good success with this using STM32F100 parts as bootloader slaves.  The HSI on the F100 has a worst case error of 2.5% (well within the 3% error most UARTs easily deal with).  The HSI on the F030 is listed as +/-5% typical over the rated temperature range, which is already too large an error for many UARTs...and the datasheet does not state what the worst case is.  Once the application is running I use the same precision HSE source for both the slave and the master, so they share the same time base in normal operation.

Does anyone have real-world field bootloader experience with the STM32F030 at temperature extremes?  It seems like the bootloader in the F030 might be doomed to failure (unless the parts are really better than the datasheet states).  I can live with the low-end F100 solution, but my project budget likes the application performance verses cost trade-off of the F030 much better.  #stm32-stm32f03-bootloader

[Nickname12657_O]

Posted on July 15, 2015 at 19:22

Hi Patrick,

What is your extreme temperature values ?  it is more at high  or cold , it may differ a bit. I believe that if used at High temperature  you should see same behavior as on our F100 serie but not at cold.  Be aware also that our F030 is a cost sensitive MCU and we relaxed our testing at factories to have reduced or extended parametric values , such as VDD limited to 2.4Volts and HSI to +/- 5%  on whole [-40°C to 85°C], and this explains the low price you may pay for less performance versus other MCU series. Cheers, STOne-32.

[Tesla DeLorean]

Posted on July 15, 2015 at 20:59

Assuming that an individual part isn't actually varying wildly (+/- 5%) at the time of testing, the way the system loader auto-bauds tends to mitigate the fact it might be off by some arbitrary amount from an ideal. It set the baud rate based on the timed data pattern from the host against it's unknown timebase, as apposed to saying this looks like 9600 baud and dividing that into the clock we ''think'' is 8 MHz. In fact the lower the baud rate, the smaller the error, as the time granularity is relatively fine.

[Nickname12657_O]

Posted on July 15, 2015 at 23:08

Hi Clive,

That is correct.  The lower is the bauds,  the better is the autobaudrate algorithm performance, Therefore more reliable the connection. Cheers,  {STOne-32}

[pmoore]

Posted on July 21, 2015 at 19:00

You bring up a good point regarding autobaud.  As long as the temperature during programming does not shift much, the relationship between the timing relative to the HSI clock during autobaud and later in communication during flash programming should not change much.  I was mistakenly viewing this from a standpoint of fixed baud rates based on the HSI clock, rather than autobaud.

[pmoore]

Posted on July 21, 2015 at 19:29

I fully understand that the STM32F030 is a cost sensitive offering with feature, process, and test trade-offs to meet those objectives.  For applications with precise timing and clock drift control, I would depend on an external timing source.  Commonly products see -20C to 85C, but in some cases -40C to 85C has been required.  On some products, reduction of application energy is applied as needed provide reduced functionality while regulating near 85C (while monitoring both the core and external temperature sensors).  One application runs continuously for years in a regulated -32C +/ -3C environment.  Normally, I try to run at clean and stable 3.3V for VDD and VDDA, but twice I have had products that have to start running as soon as VDD gets high enough that the POR allows the core to start and run until the brown-out threshold was reached...both in pulsed energy harvesting type conditions.

As Clive1 reminded me, the bootloader autobauds, rather than being in a fixed serial timing relationship with the HSI clock, which addresses the concern I raised. Thanks for the prompt reply.