i2c boot

Though this may not have a great answer, there is another thread here that has a couple of ideas for this sort of thing.

I solve this problem by writing tool that converts ccs file in compatible binary. And it works.

My next problem is i2c slave boot. Cause my code have size more than on-board EEPROM size. How can I solve this problem?

I am glad to hear your tool works.

Michael Markov said:

My next problem is i2c slave boot. Cause my code have size more than on-board EEPROM size. How can I solve this problem?

Assuming your I2C EEPROM cannot be made larger the first thing I would do is try out some reduced code size build options to see if you can make your code size small enough to fit, in particular --opt_for_space=3 and turning off the debug information with --symdebug:none, these options and more are discussed further in SPRU187. If it still cannot fit in your EEPROM than you would probably have to increase the size of the EEPROM or move to another boot method that has enough space for your application code.

Bernie Thompson said:

I am glad to hear your tool works.

Bernie Thompson said:

Assuming your I2C EEPROM cannot be made larger the first thing I would do is try out some reduced code size build options to see if you can make your code size small enough to fit, in particular --opt_for_space=3 and turning off the debug information with --symdebug:none, these options and more are discussed further in SPRU187. If it still cannot fit in your EEPROM than you would probably have to increase the size of the EEPROM or move to another boot method that has enough space for your application code.

I think our code will be lager then on-booard EEPROM. My question is: If I understand slave i2c boot mode right? I suggest that this mode allows my code can be loaded without EEPROM memory. I want to load this from other IIC device passing EEPROM.

Can I do so? If yes. How much can be this code (Is it restricted by EEPROM size)?

If restricted, an idea is in using second level bootloader, but we will not have EEPROM on our board. Sorry for my English. Do you understand me?

Michael Markov said:

I think our code will be lager then on-booard EEPROM. My question is: If I understand slave i2c boot mode right? I suggest that this mode allows my code can be loaded without EEPROM memory. I want to load this from other IIC device passing EEPROM.

It seems it was designed around having multiple C6455 devices booting off of the same EEPROM by designating all to be slaves except for one master, however I see no immediate reason that you could not simulate an EEPROM from another processor on your board that has an I2C interface to allow for booting a larger amount of code than your own EEPROM can hold.

Michael Markov said:

Can I do so? If yes. How much can be this code (Is it restricted by EEPROM size)?

This is certainly worth trying, though I have not seen it done myself, the code can be as large as your I2C addressing allows for, and looking at the boot loader manual it seems it is using two 16 bit addresses so you should have 32 bits of address space or 2^32 bytes.

Bernie Thompson said:

It seems it was designed around having multiple C6455 devices booting off of the same EEPROM by designating all to be slaves except for one master, however I see no immediate reason that you could not simulate an EEPROM from another processor on your board that has an I2C interface to allow for booting a larger amount of code than your own EEPROM can hold.

This is certainly worth trying, though I have not seen it done myself, the code can be as large as your I2C addressing allows for, and looking at the boot loader manual it seems it is using two 16 bit addresses so you should have 32 bits of address space or 2^32 bytes. I can'not find docs about it.

I think about data structure. EEPROM contaings data in 128 bit blocks and that data are read respectively block-by-block. If I will use i2c slave boot, what have I do? (use boot table splitted in 128 bit blocks or transfer boottable without splitting). Bootloader manual discribe i2c slave boot not well.

Really i2c allows address 2^33 bytes. It is enough for second level bootloader, but programm doesn't work.
 If you don't understand, I send data to IIC from the other board.

Thanks for much help from you.

Michael,

I didn't see a reference anywhere above to the following link, which describes I2C boot and gives an example.  The zip file contains utilities to convert your .out file to a boot table that can be loaded in I2C slave boot mode.

http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spraae9

Attached is some additional reference code for I2C slave boot process. There is a big endian and little endian examples, so use the appropriate one (LE uses I2Cboot and simple_le_2; BE uses I2Cboot_be and simple_be_2; both use Utilities). Each has a batch file with appropriate steps and switches to use. The starting point is the assembly file simple.s which was used to generated simple_him.out. Once you have the .out file, you can run the batch file I2Cboot.bat. The final output file of the batch run (simple.i2c.ccs) contains the data bits that would be sent in the DATA field of the 7-bit addressing mode I2C serial format. Notice that the simple.i2c.ccs is the exact same for le and be after the appropriate switches and executables are run. As you mentioned, the simple.i2c.ccs file data would need to be modified as shown below since the data can only be sent over in max 128B blocks, so it will have to be partitioned appropriately for larger boot table transfers. This example boot table can be sent in one block transfer.

Format like this:

Start, Slave add = 04, R/W=0, 0x00, 0x06, 0x00, 0x00, 0x00, 0x01, Stop Now send the boot table..

Start, Slave add = 04, R/W=0, 0x00, 0x34, 0x28, 0xd5, 0x00, 0x81, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x81, 0x00, 0x00, 0x00, 0x99, 0xa2, 0x28, 0x00, 0x88, 0x91, 0x68, 0x00, 0x02, 0xa1, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, Stop

Output of .ccs file format

1651 1 10000 1 d - Delete this

0x003428d5

0x00810000

0x00000020

0x00810000

0x0099a228

0x00889168

0x0002a120

0x00000000

0x00000000

0x00000000

0x00000000

0x00000000

0x00000000

This simple boot table simply loads a register and waits.  Although I would not advise it because of boot time, I've known of complete programs (>1MB) loaded through I2C interface to work.

Hope that helps,

Travis

tscheck, Thank you for your reply. I haven't seen your archive, but I already had loaded program by to ways.

For beginning. I have made css-file with those utilites. Then using my own utilite to convert ascii css-file to hex data which must be in eeprom.

For second way I convert to hex btbl-file.

First way. I used i2c interface to transmit data in TMS EEPROM, than default bootloader in i2c master mode loads program.

Second one. I have written so-called second level bootloader. It receives program code and data from the other device and load its in to memory as it needs. Then I call an entry point.

Can you tell me, default bootloader is using 128b blocks not in case of EEPROM structure? May I use the default bootloader in i2c slave boot mode to read not from EEPROM but from my 'other device' directly?

One qustion more. When I load example program whis led blinking it works.  When I load my own program with "printf("Hello world")" [:)], printf function doesn't works. When I use debug throuth the asm code i have seen that all functions that usually called by printf have been called, but I do not see it in the Code Composer Studio.

Thank you.

Just to be clear, the block size limitation is 128Bytes not bits.  To answer your question, yes, even in I2C slave mode, the max 128B block size must be used.  The I2C default slave boot mode relies on an external device to transfer data to the slave DSP through the I2C interface.  It is not a read operation like the I2C master boot mode.  This external master ('other device') could be another DSP or FPGA for example.  Any device that can properly operate as a I2C master should work.

Regarding the printf issue, I believe your problem is the sequencing and timing involved.  When you boot, you reset the device, at which time you can't connect to it via Code Composer Studio.  So if you boot your program and CCS isn't connected at the time it is trying to output the printf statement, you won't see it.  If you add a long timing loop, say 20seconds, before you call the printf, then that may give you enough time to attach CCS and see your message.

Let me know if that works so we can verify the answer.

Regards,

Travis

tscheck said:

Regarding the printf issue, I believe your problem is the sequencing and timing involved.  When you boot, you reset the device, at which time you can't connect to it via Code Composer Studio.  So if you boot your program and CCS isn't connected at the time it is trying to output the printf statement, you won't see it.  If you add a long timing loop, say 20seconds, before you call the printf, then that may give you enough time to attach CCS and see your message.

Let me know if that works so we can verify the answer.

I have the other opinion.

Sequence.

In CSS I load my bootloader to TMS with JTAG. Then I recieve code of the required program (int other memory, loader works in IRAM program in DDR2) and call entry point. Connection to CCS is not lost, I can toggle breakpoints for example in asm-code. May be problem in addresses? Led blinking example is in IRAM, but I was lucky because new code hasn't overwritten bootloader code. I already have tried to use Delay Loops without result.

One more question. I want to use bootloader i2c slave mode. Master is the FPGA connected to tms. What address on i2c bus must I use to write boot parameters and boot table.

When I use address 0x1 or 0xA for example and check i2c line with the oscillograph I see normal address package on the oscillograph screen. But the data sending certanly fails (cause there is no device with such address on bus, I think). When I send data on address 0x0 (AFAIK broadcast), oscillograph displays strange behavour. IAE no byte send is successful.

The i2c address for the DSP is given in the formatting example I showed above, 0x04.

Regards,

Travis

Thanks. Writing to 0x04 address is successful.

Now, I have a question about boot parameters format. Is it only example?

tscheck said:

Start, Slave add = 04, R/W=0, 0x00, 0x06, 0x00, 0x00, 0x00, 0x01, Stop Now send the boot table..

Bootloader user's guide contents the description of boot parameters table. It's size is 26 byte. First byte is a length of itself for example. You give me only six bytes in the example. What I don't understand incorrectly?

Hello, Travis. I can load the DSP Program with your boot parameters table example!

My next task is loading program that using leds. My question is in the init process. When I'm connecting to DSP with Code Composer Studio, my program (it's in assembler just writing to the leds address) works properly. Without ccs I need to setup memory map and other initialization features. How can I do it. Can you tell me what documentation can I read about it. Thanks a lot. You have already helped me much.

Hi Michael,

I guess I need to understand what you mean exactly by "memory map and other initialization features".  The device's internal memory map is already completely accessible after it boots from the internal ROM.  What register settings are you trying to adjust?  There may be peripherals or registers that aren't enabled by default that you want to enable.  To understand that you will probably have to go through the datasheet to determine.  When you run CCS, it automatically runs the .gel file associated with that device, so you can use that file as a guideline for your "init" procedure.  The gel file is usually in the CCS\boards\dskxxx\gel directory.  Usually the boot program that you load will have a "init" section at the beginning which sets up things and initializes/enables the components you need.  When complete, this branches to your main code.

Regards,

Travis

tscheck said:

Hi Michael,

I guess I need to understand what you mean exactly by "memory map and other initialization features".  The device's internal memory map is already completely accessible after it boots from the internal ROM.  What register settings are you trying to adjust?  There may be peripherals or registers that aren't enabled by default that you want to enable.  To understand that you will probably have to go through the datasheet to determine.  When you run CCS, it automatically runs the .gel file associated with that device, so you can use that file as a guideline for your "init" procedure.  The gel file is usually in the CCS\boards\dskxxx\gel directory.  Usually the boot program that you load will have a "init" section at the beginning which sets up things and initializes/enables the components you need.  When complete, this branches to your main code.

Hi, Travis. I have seen the contents of gel file so I wrote about memory map. There are memory map gel function calls In this gel-file in the StartUp() function.

I found out that leds are on 0xA0000000 address. When I write to this address after CCS connect leds are blinking. When I load program without CCS connect leds are not blinking but program is in memory correctly and registers values are proper. So I can conclude that program runs but I must setup something to let leds blink. What must I setup? And how can I use GEL functions in my code, maybe any analogues in CSL exists? To do program small I use asemmbler if I will use CSL, it will be some problems.

Hi again, Travis. When I used C code and CSL library all works properly. Also I can load big application through the i2c slave boot mode. My new task is raising speed of transmittion. I know that i2c using boot parameters table when I can set my i2c clock frequency. But you wrote to me small boot parameters table where no frequensy.

One more question. When I choose 400KHz on the master device, what frequency will be used by the bootloader?

Michael,

Sorry for the delay, I've been out for most of last week.  My understanding is that the I2C interface can run at 400Khz when booted in this mode.  The interface speed is set by your master device.  However, I've been told that it may be  possible that the i2c can receive data faster than the cpu can do checksums and put the data into memory since the PLL1 is in bypass mode.  So the actual throughput may be lower than expected. (PLL1 is in bypass mode for all boot modes except SRIO/PCI and that the i2c module frequency is CPU/6.)  Assuming 50Mhz PLL1 input clock, this would be 8.33Mhz, which is on the low end of the i2c module operating range of 8 - 12Mhz.  66Mhz would put you on the higher end and may speed it up. Depending on your results, you may want to try and send a configuration table via i2c to take the PLL1 off of bypass before sending the actual boot table.  This should work in theory, but I've checked and no one has actually verified it here.

Regards,

Travis

Thank you for the full answer. I think that PLL will not work in "full" mode even it will be confige with configuration table. My transmittion speed when PLL in bypass mode is about 3KB/s - so speed is really lower than 400KHz [:)]

I trying to use the second level bootloader (with configued PLL) as solution but I had the other problem. DSP is slave and it receive data not correctly. Some bytes are passing. What could I do wrong? And can I detect current speed of processor? And what about the boot parameters? How can I change it, when I tried to transmit more than six bytes from your example program doesn't works properly. (Using the boot parameters I can increase PLL clock if I've undestand right)

Victory! Second level bootloader works and fast. To load itself (about 30KB) takes about 10-12 seconds but big app (about 250KB using Ethernet) loads with bootloader about 7 seconds. Thank you very much.

Hello,  again.

I'm using i2c slave boot mode again, and have troubles with it.

Transmittion of my program (Second level bootloader) is success, but I think it is not running.

How can I  check, that i2c boot works properly?

Thank you.

Thanks for the answer, tscheck. It was trouble in my transmit code. Now it's working.

hi.

5228.i2c.zip file can not be downloaded.

A newer package is posted at:

http://processors.wiki.ti.com/index.php/C6474       Look for Boot Test Package

The proceedure described in the Image Handling Document is the same for all C64x devices.

Regards,

Travis