Just as a follow up this might seem like bad process management on
behalf of the tool vendor, but customers do all kinds of stupid things
and they might flash a firmware image aimed at older hw or a different
board where the image is still valid but the BSP doesn't match, or there
is a minor HW change, etc., and it's something you generally will always
want to be able to recover from.
On most of our devices for example we poll a pin at startup and if that
pin is in a know state, we always go into bootloader mode and ignore the
firmware to give users a fair shot at debricking boards on their own.
K.
On 07/06/16 19:12, Kevin Townsend wrote:
Hi Sterling,
If a faulty image is uploaded, the boot loader will fall back to the
previous image. So the process typically works, upgrade the new
image, ensure stability, then confirm it as the default image.
In my experience, if the flash is corrupted you generally want a RMA,
as these flashes should not corrupt themselves. That said, the use
case I was previously acquainted with was devices out in the field,
that required field techs to bring them in. I can see how if it’s a
consumer, re-flashing serially might be desirable.
The problem here is that an image can be valid, but the 'code' can be
bad such as an inappropriate clock setup so it locks up waiting for
the PLL to get a fix. This shouldn't happen in the real world but bad
images do get out into the wild, of course, and the bootloader will
still accept it as valid, and customers may not be able to recover
their device.
K.
