cancel
Showing results for 
Search instead for 
Did you mean: 

UART bootloader version 3.0 problems

andrewlucas9
Associate II
Posted on August 27, 2013 at 17:52

We are using STM32F205 parts.  I have developed my firmware update code based on version 3.1 of the UART bootloader.  Today we discovered a few of our devices had version 3.0 of the bootloader installed and consequently were failing the firmware update.  I have attached screen shots of the issue.  As you can see with version 3.0 the slave is driving its transmit (the master receive) line low at the same time as the 0x7f is being transmitted to it.  You can also see that with version 3.1 this behavior is not seen.  The bootloader protocol document does not seem to document this behavior anywhere on the version evolution page.  Has anyone else seen this behavior and what did you do as a work-around.

Thanks.

Andrew Lucas

#robust-vs-rigid #bootloader
3 REPLIES 3
Posted on August 27, 2013 at 18:08

Ok, but what happens if you ignore the 0x80, and respond to the 0x79?

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
andrewlucas9
Associate II
Posted on August 27, 2013 at 19:22

Thanks, that is what I am testing now and it seems to work.  

Just wondering if this behavior was changed, without documentation, what other surprises can I expect in the future?

How many versions of the bootloader should I be expected to support?

Thanks,

Andrew

Posted on August 27, 2013 at 21:02

I can't say that I've encountered the issue, the flashing applications I've written are tolerant to junk bytes while waiting for the 0x79. Seeing spurious bytes as things power up, or are cycled, should perhaps be expected, so the robust solution is to wait for the one you're looking for. If the connection is already up you'd expect to see an 0x1F NACK. If it auto-bauds incorrectly you'll get incoherent responses, and you'll probably want to prompt a reset as the measurement is a one-shot deal.

Additional commands can be sent to validate the interface.

You might have to revisit the loader if the major version changes, as it did from the original STM32F1 when the command subsets changed. I believe the commands listed for 3.0 vs 3.1 are the same. Sending 0x00,0xFF should get the supported command list, and the loader shouldn't send commands that aren't listed. Provide a warning if you encounter something newer, or outside the scope of your support.

You might want to chat with an FAE to get a better idea of what versions are out there, and if there are other pitfalls.
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..