Hi,
My customer wants to know about the detail of I2C slave (passive) boot on C6655 because this boot mode can reduce their BOM cost.
In bootloader documents, 6bytes header should be attached to the boot image. That looks :
===========================
TTxx xx yy yy zz zz, where
TT= the slave address (part of the I 2 C command word not included in the data
block) for the DSP in slave I 2 C boot mode. See the data manual for the slave
address.
xx xx = length
yy yy = checksum
zz zz = boot option
===========================
Now let me assume actual use case. The all of data chunks that host should send DSP are <6bytes header> and <C6655 Boot table>.
In this case, I believe ....
- Use xxxx = 6, yyyy = checksum considering all of chunk (0 for no-checksum), and zzzz = 1 (boot table) and then, C6655 Boot table
- Some delay should be inserted between each byte transfers.
- 6bytes header and C6655 Boot Table should be sent in Big Endian Format.
- The above transfer should be send in 1 I2C transfer sequence. It looks like <I2C start><Address><Ack><Data : 6bytes header + C6655 boot table><I2C stop>
Is my understanding correct ? As for zzzz (boot option), I could not find the detail in C6655 datasheet. I found the description in C6678 datasheet instead.
Can I assume zzzz should be 1 for boot table in C6655 ?
Background:
After confirming the detail of I2C slave boot, I would suggest the following to my customer:
I2C slave boot is very slow in boot time point of view, so it may be better to use 2nd bootloader.
I2C host can send C6655 2nd Bootloader image by following the above scheme. After sending the image, 2nd Bootloader would get started and it would initialize PLL /DDR and configure more faster I/O (just like, SPI or uPP) to get actual C6655 executable image from the host , which it is also formatted in boot table. 2nd Bootloader would handle the image and place initialized sections in system memory. After that, branch to its entry point to start C6655 application.
Best Regards,
kawada
