• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 552 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Booting C6474 through FLASH

Manimaran Subramanian
Prodigy 30 points

Hi

I have gone through various boot methods for C6474.  I would like to boot the C6474 through FLASH. (becoz more size, life, speed etc) I want to use SPI FLASH and connect SPI FLASH with DSP via I2C interface (through I2C -SPI glue logic).

I would like to take feasbility of this option and would like to know TI support (lib/src code etc) on this?

Thanks

S Manimaran

 

 

 

  • 0
    TI__Mastermind 18256 points

    Hi Manimaram,

    I'd think it would be possible to do what you describe. However there's no support from TI nor have we verified this.

    Also I'd think it would be easier to use GPIO to hook a Flash memory to the C6474. You could use I2C as a first level boot and do the second level boot from Flash. I don't believe we offer any SW for that.

     

    Kind regards,

    one and zero

     

  • 0
    TI__Guru* 84110 points

    The available hardware boot modes are only the ones listed in the datasheet, which you have already looked over.

    You have likely already read through the Bootloader User's Guide SPRUEC6, which explains the syntax required and the capabilities of the I2C boot options.

    The easiest solution would be to use the 256Mbit CAT24C256WI-G that is used on the EVM. It is verified as working and the schematic shows you exactly how to hook it up.

    You can always do extra stuff using your own glue-logic, but you will have to make the SPI Flash look exactly like an I2C memory with the I2C configuration that comes with the C6474 boot modes.

    If the 32KByte I2C is big enough, then that is the easiest way to go.

    I saw a 64KByte I2C from MicroChip, but I have not verified if it is compatible with the C6474 for booting. Perhaps you can make that call from your research.

    But if you want substantially larger memory and need SPI, I highly recommend using BOTH the I2C EEPROM for hardware boot and a larger SPI Flash for the real application image. The I2C memory can contain a secondary bootloader that can configure a McBSP for SPI mode, then you can read the SPI Flash to get the rest of the code.

    That sounds easier to me, using two memory chips, than adding a SPI-to-I2C interface and making sure it will work. The latter sounds like a big headache and fraught with downsides like speed and functionality.

  • 0 in reply to RandyP
    Prodigy 30 points

    Thanks Randy for suggestion.  My intention is to use available bootloaders only. However, i am not sure what could be my application image size. My application is to develop GSM baseband processing application (Receive and some kind of Tx) and SRIO as primary interface. Do you have rough estimation of code size? if it is less than 20 KB, i would prefer to use I2C EEPROM for application image. Otherwise i may have to choose another memory device for booting option. Can you please help me?

    Regards

    S Manimaran

  • 0 in reply to Manimaran Subramanian
    TI__Guru* 84110 points

    The datasheet shows you the available bootloaders, and the Bootloader User's Guide plus I2C User's Guide may be helpful. You will want to be familiar with many of the documents in the C6474 Product Folder.

    I suspect your application will be larger than 20KB. one and zero's suggestion of rigging up the GPIOs for a secondary Flash interface would give you access to more space. Or you will need to work out a way to use the other available interface ports for bringing in more program and data. Or multiple I2C devices would work, too.

     

  • 0 in reply to RandyP
    TI__Guru*** 125430 points

    In my opinion Randy's earlier suggestion to use an I2C flash for initial boot and a SPI flash for application is the best solution:

    • Nice, clean solution with no messy glue logic.
    • Fast because the SPI accesses can occur at a speed of many MHz rather than the slow I2C speed of 400  kHz.
    • Having your own secondary bootloader gets you far in terms of being able to have an application you can update in the field, i.e. your secondary bootloader could have "smarts" to erase the current image and upload a new image.  Even if the update was somehow interrupted this would be safe because your secondary bootloader would still be intact to try again.