Hi all,

I have faced some troubles with the SPI Interface of my AT91SAM9G45 Controller.
Please see the following Screenshot of my Scope.

I am using the AT91 as SPI Master SPI1 in Mode 3 -> SPCK inactive high, Shift Data on falling Edge, Capture on rising edge as this is the mode
supported by the external ADC AD7194 (SPI Slave). The SPCK frequency is 3 MHz. The plot on the scope screen shows at least the last 5 Bits of a byte transfer. It is the response of the Slave and should be 0x60. According to the screenshot the response from the slave(green) is as you would expect. But here comes the odd. In the SPI_RDR (Receive Data Register) I receive 0x61. It seems as if the Shiftregister of the AT91SAM9G45 Captures the high level on MISO(green) after the last rising edge. So i first asumed a hold violation of the last 0 bit (LSB). But with a SPCK frequency of 6MHz everything works fine. So it can't be due to hold violation.

Know I have the trouble that my ADC (SPI slave) is only specified for a max of 5MHz on SPCK. With every frequency below 6 MHz I am latching that bit.
From the Datasheet of the AT91SAM9G45 SPI is specified up to 48MHz. Are there known problems with this SPI Interface below a certain frequency.

Can someone give me an advice how to fix that Problem?

[attachment=0]SPI_LSB_BIT_RDY_LAtching_is_Problem_3MHz_1.PNG[/attachment]

a) The ADC device is generating the data on MISO (ie it's not a 9G45 problem)
b) You need to be latching the MISO data on the *rising* edge of the clock.
c) The bit 0 is being sampled off the right edge of the chart (it always help to plot the entire interaction, ideally with both ends of the CS pulse), where the clock goes low again.

If you have problem with SPI devices, try driving the GPIO's bit-bang style and observe the device that way. It makes debugging a lot easier, not saying to do that in production. Also if you are using Linux the CS placement is very sloppy.

0x60 is 01100000, that's 5 trailing zeros, and you've only got 4 low going edges when the MISO is low.

That's just looking at your plot.

Now lets read the data sheet for the part you are using, Specifically FIGURE 3
http://www.analog.com/static/imported-f ... AD7194.pdf

[attachment=0]spi2.jpg[/attachment]

Thanks for youre reply.

I've posted the entire transfer. Du to the size of the image it would be good to save the picture on youre pc to see the full image.
I don't see why I am not having five low going edges or in respect five rising edges to capture the 5 trailing low bits. The section is marked with arrows. The first low going edge is the edge that forces the high bit to go low the following high rising edge captures the data.
It is all according to figure 3 and it's timing requirements from the datasheet that you've mentioned.

Trying to do the bit banging is a good advice. But in the end I think the device is behaving as i would it expect to. I still think there is a problem with the SPI Interface at the Master side.

Do you have any buffering between the 9G45 and the ADC?

The t7 time should be at least 10 ns, while I can't measure this on your plot, assuming a 3 MHz clock, it looks to be in the order of 30 ns after the rising edge that should be latching the value.

You could increase this margin by adding buffers in the clock line between the 9G45 and the ADC, but it should be more than adequate (9G45 latching on the internal rising edge, which is a tad earlier than the external pin)

[attachment=0]spi5.jpg[/attachment]

On your original plot t7 looks to be at least 70 ns which is huge, the only way I can see you getting 0x61 is that the 9G45 is latching on the falling edge (ie SPI Mode 2, CPOL=1, NCPHA=1). You need to double/triple check what the register setting are on the SPI controller.

No there are is no buffering between G45 and ADC. Not that I am aware of.
But why does it work with 6MHz clock? With buffering between them it wouldn work either with 3 MHz or 6 MHz. I've zoomed in on the t7 time and it is always 75ns. Even for 6MHz clock.