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

sohara — Thu, 20 Oct 2016 12:12:55 GMT

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

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

jay_heng — Fri, 21 Oct 2016 03:50:43 GMT

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

topic Master CPU ARM/Linux via I2C connection to Kinetis ROM loader in MCU Bootloader

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

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