• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 827 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.

C6748 SPI Slave boot question

David Leung
Prodigy 80 points


Hi All,

In our implementation, we will be booting up the C6748 using the SPI slave boot mode.    Thus, we have to find out any limitation in the SPI clock frequency and any time delay needed between 16-bit word transmit or receive so that we can set up our SPI master (implemented in a FPGA) in a reliable and efficient manner.

I have tried to find out the above using two C6748 EVM (one acting as the SPI master, the other to be boot up in SPI slave mode) and so far I have found out the following limitations:

(a) During initial stage of boot up (before the PLL is configured by the AIS), the SPI clock frequency can be up to 3 MHz and there should be at least 29 microseconds between 16-bit read or 16-bit write.

(b) During the second stage of boot up (after the PLL is configured by the AIS), the SPI clock frequency can be increased to 11.538 MHz and the time delay can be reduced to a minimum of 2.3 microseconds between 16-bit read or 16-bit write.

Does the above findings make sense to you?   Is it possible for us to further increase the SPI clock frequency and reduce the time delay further in the second stage of the boot up so that we can reduce the boot up time?   We cannot tell as we don't have access to the source code of the bootloader in the internal ROM.   The version of the bootloader in our C6748 EVM is d800k002.   Are the above limitation in the SPI clock frequency and the time delay the same for newer versions (d800k004 and d800k006) of the bootloader?

Any help will be appreciated.

David

  • 0
    TI__Mastermind 27585 points

    Yes these numbers seem reasonable for both bypass mode and after the PLL configuration. Unfortunately other than adjusting the PLL and SPI clock frequency, there is nothing else that can be done to speed up the boot time. The same limitations exist for all current version of the bootloader.

    What speed did you configure the PLL for through the AIS command? Can you further increase this and see if that improves your timings?

    Jeff

  • 0 in reply to jc-ti
    TI__Guru*** 125430 points

    Related to Jeff's comment, note that the 6748B (i.e. Silicon Rev 2.0) is actually spec'd for 375 MHz operation at 1.2V.  The version you are using is only spec'd for 300 MHz operation.  So if nothing else you should be able to eek a little more speed moving to 6748 and increasing the PLL speed.  You could increase the speed even further if you purchase the 456 MHz version of the device (note that core voltage is 1.3V for 456 MHz operation).

    If you're really motivated I think there might be another possibility as well.  I'm making a bit of an assumption here, but I'm fairly confident it will work.  My assumption is that the current bottleneck is based on CPU interrupt latency to go service the SPI peripheral.  That being the case, you could further improve performance by writing your own bootloader that uses EDMA to service the SPI which should allow you to crank up the clock speed even further.  So in this case you would have a very tiny bootloader that would get loaded at the current speed followed by the main application which should be able to come in much faster, hopefully a lot closer to the 50 MHz maximum SPI clock frequency.  I'd guess you should at least get up to 25 MHz, hopefully better.

  • 0 in reply to Brad Griffis
    Prodigy 210 points

    Thank for Brad's comment. The tiny bootloader thing is what we are going to try. Do you think there is reference code that we can use to create this tiny bootloader? Thanks.

  • 0 in reply to Jonathan Cheng
    TI__Guru*** 125430 points

    There's nothing really great that I know of.  However, you might find some interesting info related to this topic here:

    http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/p/11700/45722.aspx#45722

    Specifically, I assume you won't want to implement your own AIS parser, so for the main application you'll want to use the hex conversion utility to generate a binary that can be sent over the SPI.  The thread above walks through some of the mechanics of using the hex conversion utility as well as the corresponding code to parse that binary generated from the hex conversion utility.

    So you would have to make your own EDMA code to blast your application binary into RAM somewhere (e.g. the start of DDR).  You could have the EDMA generate periodic CPU interrupts, eg after every 1KB is copied.  That way the CPU could start parsing the binary very quickly to copy it to its proper location as fast as possible.

    On a related note, as you begin this process please create individual threads for the various issues you encounter.  For example, don't posts issues related to EDMA configuration into this same thread.  If you have further questions about the overall procedure this thread is probably the right place.

    Best regards,
    Brad