Hi Kevin,
I’ll caveat my comments below with: I agree with you, there should be
a serial port option in the boot loader, so take the rest as capturing
thoughts in this area. :-)
Thanks for the reply.
On Jun 7, 2016, at 5:07 AM, Kevin Townsend <ke...@adafruit.com>
wrote:
Dev probably isn't the ideal place to post this, but I'm filing it
here in case the request is useful to other people in the future.
I'm trying to determine how the bootloader functions with image
management, and what functionality is currently in place, and I was
hoping someone could clarify is whether flashing only the bootloader
(on the nRF51822 in this case) is enough to allow for firmware
updates over serial?
It is not. Bootloader does not have serial port or newtmgr command
processing in it.
Image uploads/list etc commands are processed by the app itself.
Bootloader gets instructed by the app what image to boot next, and it
acts on this info
on next reset.
If you can type in console input and see responses over the serial,
then the target should
be able to process newtmgr commands as well (assuming newtmgr is
included, of course).
That seems like a significant shortcoming of the bootloader process,
then, if it relies on a valid secondary firmware image to be present.
What if a faulty image is flashed, for example, or the firmware flash
memory is corrupted resulting in essentially a bricked device that
will require a JLink to restore, which is an unreasonable expectation
in the field in my opinion.
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.
It would seem far safer to integrate the communication process into
the bootloader itself so that it's entirely autonomous, although I
understand the COM port conflict at that point as well.
For me, the bootloader should be the single, independent constant and
the main fail safe mechanism in the system with no external
dependencies, but perhaps I've misunderstood some of the design goals
as well. That's just how every other bootloader I've dealt with was
designed.
Well, that’s the case here. It just doesn’t have a serial port
option, it assumes the flashing is done either via JTAG, or OTA. This
is very similar to the Nordic option which has the MBR (boot loader),
and then the DFU<->SoftDevice, which are outside of the boot loader
region, and not self contained.
I don’t think we want the boot loader itself to provide OTA (BLE)
update, as that would make it prohibitively large (and as you point out,
the boot loader should not be upgradable, so all code there would be
fixed.)
I agree we should add a serial port option to the boot loader, it
shouldn’t be that hard, and could be optionally compiled.
Cheers,
Sterling
