• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 32 subscribers
  • Views 1105 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.

SRC4392 Initialization

Stephan H.
Prodigy 90 points
Other Parts Discussed in Thread: SRC4392

 Dear Bob,

this initialization sequence is not mentioned in the datasheet at all. So I'm a little surprised that it is the recommended sequence. Is it needed in every case?

I'm trying to initialize a SRC4392 via SPI on a new self-built hardware, which I have done successfully before on other hardware. But now it won't work, though I am sure the data I send is correct. SPI mode and clock setting should not be the problem. The core is powered from a separate 1.8V regulator, which I did in this way successfully before.  CPM is directly connected to ground.

The SRC reacts correctly on the MSB of the first byte (R/W), but everything else it does is not correct. In more detail:

- If the MSB of the first byte is 0 MISO is not enabled, if it is 1 data is put out on MISO. So I assume the configuration interface is working.

- If the MSB is 1, MISO is enabled directly, and not kept high Z for the first two bytes as described in the datasheet. 

- The data on MISO is changing on both edges of the clock. The data sent is always the same. Something like 0xF8 for the first byte and 0xC3 for all other bytes, if the edges were correct.

- If I try to configure the SRC by writing data, I get no effect at all (I tried to set an GPO for testing).

Is there anything about power up, the application of the audio clocks, the core or something else which must be considered for a correct response from the SPI? 

Best regards,

Stephan.

 

 

 

 

 

 

 

 

 

 

 

 

 

  • 0
    TI__Guru**** 189401 points

    Hi, Stephan,

    I hope you don't mind, but I split your post off the other thread (http://e2e.ti.com/support/data_converters/audio_converters/f/64/t/63587.aspx).

    Unfortunately, Bob is no longer with TI, but I have asked my colleague to look at this for you.

    -d2

  • 0 in reply to Don Dapkus
    Prodigy 90 points

     Thanks Don.

    What I've found out is, that on my target hardware the Chip-Select pin of the SRC4392 is toggled multiple times during startup of the hardware, what I can't change at the moment. Maybe the SRC is disturbed during his power-on reset by this? 

    After the Hardware and the SPI-master have come up, I do an additional reset, with all SPI pins in a defined state, but this doesn't help.

    For reference I included a screenshot of the signals taken with a logic analyzer.

    Best regards,

    Stephan.

     

     

     

     

    To complete the thread, here is the procedure given by Bob referenced by me:

     The following sequence should be used to initilaize the device.

    1. Apply power and external reset.

    2. Write all control registers on Page 0 except register 0x01.

    3. Apply MCLK, as well as any audio clocks desired for Ports A and B.

    4. Write register 0x01 on Page 0 to power up the desired blocks.

    5. Disable DIT buffer transfers by setting the TXBTD bit in register 0x08, Page 0, to a 1.

    6. Write 0x02 to register 0x7F to set Page 2 as the active page.

    7. Write data to the DIT C and U buffers on Page 2 as desired.

    8. Write 0x00 to address 0x7F to set Page 0 as the active page.

    9. Enable DIT buffer transfers by setting the TXBTD bit in register 0x08, Page 0, to a 0. This will update the DIT TA buffer with the data written to Page 2 registers.

  • 0 in reply to Stephan H.
    TI__Guru 62386 points

    Please attach a screenshot of the SPI communication that also shows the chip select signal.

  • 0 in reply to Dominik Hartl11
    Prodigy 90 points

     I actually don't have a picture of the CS signal. But it is set around 1 ms before the transfer starts and released  about after 1 ms  after the transfer of the last byte . So there should be more than enough time.

    Is it possible, that the SRC4392 is very sensitive on it's SPI-lines?  Does the substrate GND have an influence on this?

    Best regards,

    Stephan.

     

     




  • 0 in reply to Stephan H.
    TI__Guru 62386 points

    As long as the timing specs in the d/s are observed, the SRC4392's SPI interface will work. The GND will influence performance, if it's noisy enough to interfere with logic level margins (which it won't unless there's some really bad GND design - unlikely).

    To debug this, more information about the actual interface timing of all SPI signals, measured on a scope, not estimated by design, is needed.

  • 0 in reply to Dominik Hartl11
    Prodigy 90 points

     I actually solved the problem. The SPI of teh SRC is very sensitive electrically ans reacted to some ringing on the CLK line, which did not cross any logic levels. All other devices on the same SPI bus work absolutely reliable.

    I just loaded the clock line near the SRC with a resistor to overcome this problem. What SPI termination scheme do you recommend in general for the SRC?

    Best regards,

    Stephan.

     

     

     

     

  • 0 in reply to Stephan H.
    TI__Guru**** 189401 points

    Hi, Stephan,

    I just checked the EVM Users Guide (here), and we don't have any termination on the SPI lines, so I think the termination is system-dependent, and we really can't make any generalizations on recommended terminations.

    -d2