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

RM48L952: SPI4 delay between block transfers

Jamie Wardlaw
Expert 1895 points
Part Number: RM48L952

Hello,


We are using SPI4 on the RM48L952PGE package to communicate with an analog devices AD5421 DAC. So far we have been unable to get a response from the DAC, effort has been put in to duplicating the protocol format obtained from the Analog devices development platform. You can see in the screenshot below the development systems message and response (channels 00 to 03) and the format of our communications (channels 04 : 07). It is a 24bit or 32bt transfer, as shown below we are running in 24bit mode just now, the SPI4 is set for transfer of 3 x 8bit blocks.

It looks like the correct message is being sent but there are three key issues I have been unable to resolve

1. The delay between consecutive block transfers on the RM48 ,can this be reduced so that they are truly consecutive? reduce the time A1-A2 to zero?

2. Can the clock be launched prior to the first EN active transition? I don't think it should matter, but the evaluatlion board does start clock up far in advance of sending the first block

3. Is there a setting for the default status of the MISO channel on the RM48 (ch07 in screenshot)? I cannot get it to go low, seems to be constantly held high. If this is not an MCU side issue I can debug further on our hardware configuration.

I think "1" could be the critical problem here, I have reached out to analog devices as well but their support is less than prompt.


Thanks

Jamie

  • 0
    TI__Guru 68920 points
    Jamie,

    There is some minimum time between transfers on the SPI ... it won't run continually like an I2S port.
    I think you could reduce the time A1-A2 by using 16-bit transfers instead of 8, and by using the multibuffer mode
    to have multiple transfers queued up before starting so that there is no latency between transfers due to the CPU or DMA.
    But you will probably see at least a few VCLK dead time; and if you have the DELAY parameters set this can be even longer.
    So check what you have done for WDEL and other delay fields like C2T, T2C, ... in the SPI control registers.

    The ADI datasheet does say the port is SPI compatible so I am not sure this is the problem.

    Are you using the RM48 SPI as a master or slave? I'm having a hard time understanding the two clocks in the logic analyzer shot and why
    there seems to be a free running clock on the DAC. (my first thought was it has more of an I2S interface but I didn't find that backed up in the datasheet.)

    Regarding your Q2 you can control the phase and polarity of the clock but I don't know if that gives the degree of freedom you are looking for.

    For Q3, need to know the background. Is this the Master In - Slave Out pin, and you are operating in Master Mode, and you want to know if you can force this input to a given state?
  • 0 in reply to Anthony F. Seely
    Expert 1895 points

    I will look more closely at our PCB circuit before trying to get the multi-buffered driver running. Or as you say I could jump to trying the 32bit format of the protocol to reduce this period between blocks.

    The AD5421 evaluation board is connected as slave to the Analog devices SDP-B platform board, UG-250 datasheet from Analog devices describes the setup. I assumed that it is driving using SPI and they have simply programmed up the SDP-B to throw the clock in early, it is not actually free-running 100% of time. The screen shot below shows how early it is before the enable active.

    I think I have the clock phase and polarity conforming to the DAC requirement, I don't see why they need to start it up so far in advance of EN active. I will assume for now this is not an issue.

    Yes channel 7 is the Master In-Slave out. It should be the same as Channel 03 activity on the evaluation board. I'm going to look at this in more detail as maybe our circuit is pulling it up or we have integrated the DAC incorrectly. I see no reason for the pin to be held high all the time when it is connected to the SDO pin of the AD5421 DAC.

    Will let you know how I get on.

  • 0 in reply to Jamie Wardlaw
    TI__Guru 68920 points
    You might drive yourself crazy trying to get the RM48 SPI to produce exactly the same signals as the UG-250.

    It looks like they have this connected to something called a "SPORT", not to their SPI. SPORT I remember from my days working on Audio DSPs at TI, it was similar to our McASP. I think it's really a different sort of beast that is designed for I2S or TDM with a free running clock and 'frame sync' signal to mark the channels ... it probably has some sort of SPI emulation [I'm not an ADI expert ;) ] but if it were really good I don't see why they would have the SPI pins left unconnected above it in the schematics.

    The DAC probably can speak to multiple different types of serial ports so I'm thinking that you will get the most mileage just trying to find a common protocol that the RM48 SPI speaks and that the DAC understands, rather than trying to go about this by making the SPI speak SPORT which it doesn't...

    Thanks and Best Regards,
    Anthony
  • 0 in reply to Anthony F. Seely
    Expert 1895 points
    I see that now, on page 8 of the UG-250 datasheet. The DAC does work with multiple different SPIs. I'm inclined to think we have an issue with our circuit which is why we see no activity on the Master In - Slave Out line. The fact it is continually pulled high right now seems to be something to investigate further.

    Thanks again.