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.

AMC7812: SPI reads are occasionally bad

Part Number: AMC7812

Hello,

We have found that the double-read SPI mechanism to read from the AMC8712 is causing us an issue. We are using a Linux OS which has it's own SPI driver but with our own user-space controlling the Chip-Select (CS) line.

Sequentially we pull the CS low, perform a single read operation, then pull the CS high and repeat this sequence to get data from a AMC7812 register. When we view the a single transaction on the scope we see CS go low (correct), Clk go low then toggle with MOSI and MISO  data as expected...then we see CS go high before the Clk line is driven high by the linux kernel. Strange that Clk stays low longer than CS but it works!

What's even more baffling is that sometimes we see CS go low (correct), Clk, MOSI and MISO  toggle as expected...then we see Clk go high before the CS and in this case the data back on the MISO line is always 0's. This is happening even when we read from register 0x6C which should always read 0x1220.

Why would CS going high after Clk cause an issue? What could the AMC7812 be doing that returns 0 when it's gated with 24 clock cycles and the correct MOSI register address?

  • Hi Peter,

    The CLK line rises before CS is high, then you are violating the timing requirements of the device.  Timing limit t10 requires that the CLK rise at minimum 3ns after CS rise edge.

    This device supports daisy-chain mode, meaning that it expects valid commands to be in increments of 24×N clocks.  The rising edge is causing the device to assume that there is a new bit that needs to be latched on the next falling edge.  If the number of bits latched does not equal 24×N, the device will reject the command.

    The AMC7812 is purely an SPI slave, so your SPI driver must be having this issue.  To see if your phase and polarity seeings are correctly configured on the bus.

    Thanks,

    Paul

  • Thanks for the response Paul.

    Our default sequence correctly sends the 24 bits and we do see 24 clock transitions, this is working. I believe the relationship between CLK and CS is what was/is the issue for is. Normally we'd expect to pull CS high after the relevant transactions but for the 7812 this is not the case. The key piece of information you have provided is "Timing limit t10 requires that the CLK rise at minimum 3ns after CS rise edge" as this is where we see an issue.

    Again, thanks for the response as it has cleared up some of the unknowns for us.

    Peter