Hi Marko,
Thanks for the reply.
On Jun 7, 2016, at 5:07 AM, Kevin Townsend <[email protected]> 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.
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.
K.
