AnsweredAssumed Answered

Master CPU ARM/Linux via I2C connection to Kinetis ROM loader

Question asked by Shawn O'Hara on Oct 20, 2016
Latest reply on Oct 20, 2016 by Jay Heng
We have a new product application  our  host is an embedded ARM master processor running Linux with the  I2C0 interface to the Kinetis MKL17Z128VFT4 for in system Kinetis  updates.  There does not seem to be any developed utilities to  accomplish this and it's confusing to determine the best path. 
QUESTION: Would  you agree that the most efficient (code size and dev time) would be the  take the demo code made for UART and convert it to I2C?  Or is there some other example or idea you recommend?
Also have these questions:
The  following questions pertain to transferring a binary image across I2C  to a kboot bootloader-enabled kinetis (KL17Z, presumably kboot V1.0  onboard in ROM).  You can assume the Kinetis flash has already been  completely erased either via the bootloader or due to the part being  blank.


Cannot find answers to these questions in kboot reference manual or anywhere else.

1.) When transferring data via I2C and using  the WriteMemory tagged command packet, what is the max number of data  packets that can follow the WriteMemory command packet?


2.)  What is the max number of data bytes that can be contained in a single  data packet that follows the WriteMemory command packet?


3.)  Does the data from the data packet get written immediately to flash  (assume that a valid flash start address was provided in the command  packet) before the bootloader sends the ack response packet back to the  host?


4.) How does the kboot bootloader respond to  any packet it receives where it computers the CRC16 and the result  doesn't match the provided CRC16 in the packet?  The reference manual  doesn't appear to detail this case.


5.) Does the  bootloader have some way of knowing a valid program has been put into  flash, or does it just blindly jump to the start address that was set  within the bootloader by the host?


6) How do we manage the whole image integrity, packetized CRC only? and are retries built into the ROM loader?
Hi Shawn O'Hara,
Thanks for your detail description.
In my opinion, regard to the design, the ARM master processor's job is as same as the Blhost PC tool.
About the above questions, you'd better to have a look through the KBOOT's protocol prior to any
working, I think the KBOOT's protocol has already clarified these questions.
And I'd highly recommend you to refer to the Embedded Host User's Guide ( The Embedded host application or tool is new and differentfrom PC-based tools. It provides an example implementation of code running on an embedded platform host and communicating over serial connection to flash the target device. The application is similar to your design.

Hope it helps.

Have a great day!

Wednesday, October 19, 2016
We are asking those questions because the kboot reference manual is NOT clear on any of those items we have questions on.  We'd rather not have to reverse engineer the blhost, firmware loader applications, or embedded host application to find information that really should be in the kboot reference manual.

If the questions above are answered in the reference manual somewhere, please point us to the page or section for those answers.  I have been through the entire manual for both the embedded host and the entire reference manual for kboot and that's where my questions come from.
Thursday, October 20, 2016
I'd highly recommend you to create thread about the steps of simulate blhost tool reside in the ARM master processor, then send me the link and I will contact with the my coworker who is from the KBOOT development team to answer it.
I think it's efficient way to support you.
I'm looking forward to your reply.
Have a great day!