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.

Is the clock for SPI0 (Serial Peripheral Interface 0) tied to the clock for Shared RAM, and DDR2/mDDR?

Other Parts Discussed in Thread: TMS320C6748

Regarding the C6748:

Is the clock for SPI0 (Serial Peripheral Interface 0) tied to the clock for Shared RAM, and DDR2/mDDR?

Here is my issue:  I need to greatly slow down the SPI0 clock so it can talk to a particularly slow external device.  (Even when I maximize SPI0's prescaler (frequency divider =255), the frequency is still too high.)  So it looks like I have to reduce its system clock (PLL0_SYSCLK2) in order to get SPI0 to clock at a low enough frequency. The problem is, this same clock -- PLL0_SYSCLK2 -- ALSO controls the speed of memory accesses, such as Shared RAM and DDR2/mDDR, thereby greatly slowing them down too.  I am reading this interpretation from the TI TMS320C6748 DSP System Reference Guide (sprugj7d.pdf), page 58, Table 6-1, System Clock Domains, and page 59, Figure 6-1, Overall Clocking Diagram.  Am I correct in my understanding?  (That seems like an odd clocking interaction...)

Is there a way around this clocking problem?

[Note: It appears from the above references that the other SPI interface -- SPI1 -- doesn't have this weird clock interaction, So perhaps using SPI1 (instead of SPI0) could offer a solution.  However, it is not yet clear to me whether SPI1 is available when using the the LogicPD TMS320C6748 EVM board with its user interface board attached -- as in my circumstance.]

Thanks for your help.

 

  • Do you know what the maximum SPI clock speed your external device can handle is?

    Jeff

  • Slowing down SYSCLK2 is not a good option because you would have to also slow down the DSP frequency (note the ratio requirement between SYSCLK2 and SYSCLK1). Using SPI1 is a better option because you can slow down its reference clock (PLL1_SYSCLK2) without affecting other modules. Note that you'll have to configure the clock generator to use PLL1_SYSCLK2 as a source for the SPI1 internal clock (see ASYNC3_CLKSRC).

    SPI0 is muxed with the Ethernet PHY on the Logic board.  The SPI  flash on the board is actually connected to the SPI1 port. 

  • Also, can you explain how you are connecting your external device to the EVM? Are you using one of the headers on the baseboard or UI board?

    Jeff

  • Jeff,

    I'm looking at connecting the external device to SPI0 through connector J13 (the PMDC connector -- whatever PMDC is..., pins 10, 12, 14), or to SPI1 through connector J30 (the Audio Expansion connector, pins 63, 64, 65) -- both are on the EVM baseboard.

    I'm looking at making a mini-daughter card that mates with one of those connectors.  The mini-daughter card would simply provide connections (TTL compatible???) to the external device.

    The clock (and data) expected by the external device can be no faster than ~18.88 micro-Second period, which is less than 52,966 Hz.

  • In that case just use SPI1 on the J30 connector. You can slow the SPI1 clock down and only affect the peripherals running off of PLL1 SYSCLK2.  However you will have to deal with the contention of the boot flash on the SOM, possibly by removing U3 altogether.

    Jeff

  • Jeff,

    You indicate that both SPI interfaces (SPI0 and SPI1) won't work for my needs. That is, SPI1 is already used for the boot flash memory on the SOM.  And SPI0 is tied to 1/2 the CPU clock and (even with the prescaler set to the maximum of 255) it can't be slowed down enough to work with my peripheral.  It's a Catch-22:   SPI0 is available, but can't be slowed down enough, and SPI1 can be slowed down enough, but isn't available.  Ugh!  (Please correct me if I have that wrong.)

    Anyway, that shoots down my idea...

    Also, it gives me pause, because I was quite a ways down the road with interpreting the EVM schematics as indicating the SPI1 was available.  (It wasn't until you suggested I look at the SOM schematics that I discovered my error.) This suggests that when the EVM schematic shows a given signal-line on a given connector, that doesn't mean that signal-line is available for my use.  This spooks me because connector J30 clearly shows the signal lines for SPI1, thereby suggesting this is the purpose of this connector -- yet I now see SPI1 is unavailable -- so what's the point of connector J30?  And how can I rely on the other connectors, etc.  Must I trace all lines, say, back through the User Interface board, onto the EVM baseboard, then onto the SOM board -- and decode all that -- before I can discover which lines are usable?  Have I properly expressed my confusion?  Please unconfuse me...

    [A note added later...]

    Wait, I can use the Chip Select pin to avoid contention between my peripheral and the other peripherals already on the SPI1 port.  So, my idea still has possibilities. All I have to do is use SPI1_SCS[2] or SPI1_SCS[3] for my peripheral.  Cool.  (... So it took me a while to catch on...)

    [Still another noted edited in later...]

    I'd likely need to switch clock speeds after power up.  That is, I'd read-in the flash memory quickly, with the usual fast clock.  Then after the software is loaded I could slow the clock down for my peripheral device.  It's sounding do-able.

     

    =============

    I came across what seems to be a typo in the TI TMS320C6748 DSP System Reference Guide (sprugj7d.pdf).  On page 134 it says:

    "Peripherals in the ASYNC3 domain are clocked off from either PLL1_SYSCLK2 or PLL0_SYSCLK2. Furthermore, PLL1_SYSCLK2 must always be /2 of the CPU clock frequency."

    I believe that should be PLL0_SYSCLK2, not PLL1_SYSCLK2. If that second sentence were true, it would defeat the purpose of the first sentence.  Also, see how the above quotation contradicts page 70, Table 6-9. "Asynchronous peripherals are not required to operate at a fixed ratio of the CPU clock."

  • Yes, if you plan on making a custom board using of of the connectors, you should trace all the lines back to the chip itself to verify theres nothing else on the bus. In this case, it revealed you need to use another chip select, but it could mean other things for other peripherals.

    You solution sounds like it should work.

    Jeff

  • I can report that I was able to get it to work fine.

    That is, I was able to greatly slow the clock for SPI1 (Serial Peripheral Interface Port 1), without adversely affecting anything else. 

    To avoid collisions with the EVM flash memory (which also uses SPI1) I had to use the chip-select feature on the SPI port, plus I had to wait until after the flash memory is done loading into memory before changing the clock to SPI1. 

    It works fine. I hope this is encouraging to others who might try the same thing.