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

[sohara]

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?

7:00 PM

jeremyzhou

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 (http://cache.nxp.com/files/microcontrollers/doc/user_guide/EMBEDDEDHOSTUG.pdf?fsrch=1&sr=1&pageNum=1). 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!

Jeremy

11:53 PM

Wednesday, October 19, 2016

ANDY HONECKER

Jeremy,
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.

7:08 AM

Thursday, October 20, 2016

jeremyzhou

Hi,
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!
Ping

[jay_heng]

I think you can find all the answers to your questions from Figure 5-6 Protocol Sequence for WriteMemory Command in kboot RM v2.0.0.

Let me answer your questions one by one:

1). When you issue write-memory command, You must first specify startAddress and dataLength in the WriteMemory command packet, so device should know the total data bytes to write before receiving any data packet, then device will count the received data bytes while receiving data packet, when the amount of received data is matched with the total num, then device will stop receiving data. so the max num of data packet depends on the actual bytes in each data packet.

For example: if you want to flash 100 byte by WriteMemory command, and you put 10 byte data in every data packet, then you need to provide 10 data packets. but if you put 25 bytes data in every data packet, then you just need to provide 4 data packets.

2). The max num of data bytes in single data packet is 32, because device bootloader only offer a 32 byte memory space to buffer received data. this restriction is just for ROM-resident bootloader, if you are playing with flash-resident bootloader, then you can customize the max num of data bytes.

3). When your specified memory is SRAM, the answer is yes. When the specified memory is FLASH, the answer is not necessarily, because there are two methods for bootloader to program flash memory, Kinetis FTFx memory module provides two basic Program command (ProgramWord(4 or 8 bytes) or ProgramSection (1K bytes)), bootloader implements both methods in source code, but each time we can only use one method, the default method may be different in different device, you need to check BL_FEATURE_ENABLE_FLASH_PROGRAM_SECTION in bootloader_config.h file.

if this macro is set to 0, then bootloader will progam data immediately before sending the ACK to host.

If this macro is set to 1, then bootloader will buffer received data to 1K bytes, at this time, the ACK sending from bootloader just means that the data has been received properly.

4). When bootloader gets a packet from host, if the CRC16 verification is passed, then bootloader will just give a ACK packet to host, but if it fails, then bootloader will give a generic responce packet to host which indicates error code.

5) / 6). See chapter 2.7 Application integrity check in kboot RM v2.0.0.

Best Regards,

Jay