I2C Slave Boot for C6455

I am trying to find out if it is possible to do a I2C slave boot with
a C6455 DSP. According to the TMS320C645x Bootloader (SPRUEC6B)
document, it seems that it would be possible, but I have not had any
luck getting it to work.

My understanding is that:
1) Upon being released from reset, because BOOTM[3:0] (AEA[19:16]) are
configured as 4'b0110 as specified in SPRUEC6B, the DSP is put in I2C
Slave boot mode.
2) The DSP then waits to receive data from an I2C Master device (in my
case, an FPGA). The SPRUEC6B document states, "In the I2C Slave boot
mode, the DSP is programmed as an I2C slave and waits for an I2C
Master to send data, using a standard boot table format."
3) It would seem that I do not need to prepare a boot parameter table
to write before the actual boot table.

So I have tried converting my COFF output file with hex6x and some
custom perl scripts to a binary file, and then use an FPGA to write
the binary data to the DSP device. I have tried writing just the boot
table, and I have tried writing a boot parameter table and boot table
as well.

I write the following to the bus:
1) + : 0x00
2) The data from my boot binary file, byte by byte.

I also did an experiment to see if the DSP was responding. Using an
oscilloscope I can see the transactions on the I2C bus. The DSP I2C
interface is sending ACKs, and I can write the entire binary data
without any hang-ups or bus errors. Also, after writing a few bytes,
I paused the execution of the FPGA, and then I connected the DSP to
CodeComposer Studio via JTAG and looked at the I2C registers located
from 0x02B04000. In the data receive register (I2CDRR), the data I
wrote to the I2C bus was not present. HOWEVER, the RSFULL flag in the
status register (I2CSTR) is standing, meaning I have an overflow
problem and the receive shift register (I2CRSR), that unfortunately is
not accessible directly, is not being read by the bootloader.

I called my DSP supplier who at first said I2C slave boot is not
possible and he has never seen it done with other DSPs. "But it is in
the documentation," I protested! So he is checking with TI
themselves, but it takes days and days for TI to get back to us. I
was hoping that someone else has done this before and might be able to
offer some advice.

I have some questions, specifically:
1) I am on the right track? Is my understanding correct?
2) Can I write just a boot table (as generated by hex6x)? Do I also
need a boot parameter table?
3) If a boot parameter table is required, am I free to set the Device
address LSW and Device address MSW fields to any address? Is there a
specific address that it needs to start from?
4) Is it necessary to write the slave address and R/nW bit to the bus
in the beginning?

Thank you for your time and help!

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Bryan,

On Jan 29, 2008 8:50 PM, Bryan wrote:
> I am trying to find out if it is possible to do a I2C slave boot with
> a C6455 DSP. According to the TMS320C645x Bootloader (SPRUEC6B)
> document, it seems that it would be possible, but I have not had any
> luck getting it to work.
>
> My understanding is that:
> 1) Upon being released from reset, because BOOTM[3:0] (AEA[19:16]) are
> configured as 4'b0110 as specified in SPRUEC6B, the DSP is put in I2C
> Slave boot mode.
> 2) The DSP then waits to receive data from an I2C Master device (in my
> case, an FPGA). The SPRUEC6B document states, "In the I2C Slave boot
> mode, the DSP is programmed as an I2C slave and waits for an I2C
> Master to send data, using a standard boot table format."
> 3) It would seem that I do not need to prepare a boot parameter table
> to write before the actual boot table.
>
> So I have tried converting my COFF output file with hex6x and some
> custom perl scripts to a binary file, and then use an FPGA to write
> the binary data to the DSP device. I have tried writing just the boot
> table, and I have tried writing a boot parameter table and boot table
> as well.
>
> I write the following to the bus:
> 1) + : 0x00
> 2) The data from my boot binary file, byte by byte.
>
> I also did an experiment to see if the DSP was responding. Using an
> oscilloscope I can see the transactions on the I2C bus. The DSP I2C
> interface is sending ACKs, and I can write the entire binary data
> without any hang-ups or bus errors. Also, after writing a few bytes,
> I paused the execution of the FPGA, and then I connected the DSP to
> CodeComposer Studio via JTAG and looked at the I2C registers located
> from 0x02B04000. In the data receive register (I2CDRR), the data I
> wrote to the I2C bus was not present. HOWEVER, the RSFULL flag in the
> status register (I2CSTR) is standing, meaning I have an overflow
> problem and the receive shift register (I2CRSR), that unfortunately is
> not accessible directly, is not being read by the bootloader.
>
> I called my DSP supplier who at first said I2C slave boot is not
> possible and he has never seen it done with other DSPs.

This is "old data". All C6000 devices PRIOR to the c672x and c64+ only
supported hardware/state machine boot modes [HPI/PCI/memory]. The
c672x and c64+ contain internal ROM boot loaders for I2C.

> "But it is in
> the documentation," I protested! So he is checking with TI
> themselves, but it takes days and days for TI to get back to us. I
> was hoping that someone else has done this before and might be able to
> offer some advice.
>
> I have some questions, specifically:
> 1) I am on the right track? Is my understanding correct?
Yes.
> 2) Can I write just a boot table (as generated by hex6x)?
Yes, but check it manually.

> Do I also
> need a boot parameter table?
No, if it is not not spec'd in the boot table.

I would suggest creating a small "test pattern only" boot test with 3
or 4 hex patterns at some internal memory address. This will simplify
troubleshooting. Manually check and verify all of the bytes and see if
they get written correctly with CCS.
Also, I assume that clock in is < 50 Mhz [per spec].
Take a look at the PERCFDx and PERSTATx registers to verify that I2C is enabled.

> 3) If a boot parameter table is required, am I free to set the Device
> address LSW and Device address MSW fields to any address? Is there a
> specific address that it needs to start from?
> 4) Is it necessary to write the slave address and R/nW bit to the bus
> in the beginning?

Yes. You must follow the I2C protocol.
You also need to ensure that the I2C clock rate is in spec.

mikedunn
>
> Thank you for your time and help!
>
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Bryan-

> I am trying to find out if it is possible to do a I2C slave boot with
> a C6455 DSP. According to the TMS320C645x Bootloader (SPRUEC6B)
> document, it seems that it would be possible, but I have not had any
> luck getting it to work.
>
> My understanding is that:
> 1) Upon being released from reset, because BOOTM[3:0] (AEA[19:16]) are
> configured as 4'b0110 as specified in SPRUEC6B, the DSP is put in I2C
> Slave boot mode.
> 2) The DSP then waits to receive data from an I2C Master device (in my
> case, an FPGA). The SPRUEC6B document states, "In the I2C Slave boot
> mode, the DSP is programmed as an I2C slave and waits for an I2C
> Master to send data, using a standard boot table format."
> 3) It would seem that I do not need to prepare a boot parameter table
> to write before the actual boot table.
>
> So I have tried converting my COFF output file with hex6x and some
> custom perl scripts to a binary file, and then use an FPGA to write
> the binary data to the DSP device. I have tried writing just the boot
> table, and I have tried writing a boot parameter table and boot table
> as well.
>
> I write the following to the bus:
> 1) + : 0x00
> 2) The data from my boot binary file, byte by byte.
>
> I also did an experiment to see if the DSP was responding. Using an
> oscilloscope I can see the transactions on the I2C bus. The DSP I2C
> interface is sending ACKs, and I can write the entire binary data
> without any hang-ups or bus errors. Also, after writing a few bytes,
> I paused the execution of the FPGA, and then I connected the DSP to
> CodeComposer Studio via JTAG and looked at the I2C registers located
> from 0x02B04000. In the data receive register (I2CDRR), the data I
> wrote to the I2C bus was not present. HOWEVER, the RSFULL flag in the
> status register (I2CSTR) is standing, meaning I have an overflow
> problem and the receive shift register (I2CRSR), that unfortunately is
> not accessible directly, is not being read by the bootloader.
>
> I called my DSP supplier who at first said I2C slave boot is not
> possible and he has never seen it done with other DSPs. "But it is in
> the documentation," I protested! So he is checking with TI
> themselves, but it takes days and days for TI to get back to us. I
> was hoping that someone else has done this before and might be able to
> offer some advice.

Who is your "DSP supplier"? Do you mean the board vendor? If so, then a) he/she
should know better about I2C boot and b) it shouldn't take "days and days" for them
to get back to you. Are you not in the US? You should be able to ask this type of
question to the TI hotline and get a 1-day response. As you might expect, response
time on this group or comp.dsp would be even faster.

-Jeff

> I have some questions, specifically:
> 1) I am on the right track? Is my understanding correct?
> 2) Can I write just a boot table (as generated by hex6x)? Do I also
> need a boot parameter table?
> 3) If a boot parameter table is required, am I free to set the Device
> address LSW and Device address MSW fields to any address? Is there a
> specific address that it needs to start from?
> 4) Is it necessary to write the slave address and R/nW bit to the bus
> in the beginning?
>
> Thank you for your time and help!
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Mike-

> I would suggest creating a small "test pattern only" boot test with 3
> or 4 hex patterns at some internal memory address. This will simplify
> troubleshooting. Manually check and verify all of the bytes and see if
> they get written correctly with CCS.
> Also, I assume that clock in is < 50 Mhz [per spec].
> Take a look at the PERCFDx and PERSTATx registers to verify that I2C is enabled.

I took a look at PERCFDx, PERSTATx, and DEVSTAT and I2C is configured and enabled. Slave boot has
also been properly selected, and if I do nothing and just leave the DSP waiting for data I can see
the program counter is 0x001014B0 which would seem to be in the memory area around the ROM
bootloader. When I send data, however, the I2CSTAT RSFULL flag stands and the data is never moved
to the I2CDRR register. I was running at 100 kHz for the I2C SCL line, but I dropped it down to
7.5 kHz, which the bootloader docs says is the default (CLKIN1/6600). It has not made a
difference though.

I will give it a try with smaller data and see if I can get the DSP to receive a byte of data in
the I2CDDR. I shall report back later. Thanks for the ideas!
Jeff-

(I accidentally sent the reply to only you, so I'm reposting for the rest of the group.)

I am in Japan so I can't work directly with TI support in the USA. They forward everything I send
over the web to TI Japan. The DSP supplier is the company that supplies the DSPs to us.
Currently we are working with the supplier who is working directly with TI Japan, no one is sure
about the proper format of the data that needs to be sent. It seems everyone has a different
interpretation on the documentation. So they are going to be working directly with TI USA to find
some sort of definitive answer.

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

I thought I would update this thread with some more information.
Hopefully it will be helpful to anyone who tries to do I2C boot from
now on.

Regarding I2C Slave boot, I have still not been able to get it to
work. No word from TI either.

I2C Master boot is working though. There is a critical error in the
documentation, TMS320C645x Bootloader (SPRUEC6B). As described in
section 2.3.4.1, I2C EEPROM Data blocking is required for I2C boot
roms. The boot table must be broken into 124-byte block, and a block
length and checksum are attached to the head of the block, creating a
128-byte packet. The document does not mention if the length is
supposed to include this 4-byte header or not. It is required though,
as my testing proved.

As for the checksum, the documentation says, "A value of 0 in the
checksum field disables the checksum check." EVEN THOUGH it says
this, you have to generate the checksum and put it in the block. If
your firmware is less then 124 bytes, it appears that there is no need
for the checksum. I suppose this is because there is only one block
of data. But for anything longer than 124 bytes (multiple blocks),
the block needs the checksum. Finally, the boot parameter table
checksum it is not needed. The checksum is only needed for
multi-block boot table data.

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread