Page 4 of 5

Re: SPI data transfer issue

Posted: Thu Jul 21, 2011 10:08 am
by xol
HI,
I did not understand what is actually your question?

Re: SPI data transfer issue

Posted: Thu Jul 21, 2011 10:48 am
by amaitra
It does not work! That is the prolbem and my question is what to do! The rest is data I am giving from what I know.

The problem seems to be; write to 6802-2 works ok, 6802-2 outputs the correct data on SPI bus. But the sub-20 reads it incorrectly - value at the USB level and "library" on PC is not what was on the SPI bus.

One point (pointed out in the mail) - 6802-2 does reads/writes on the rising edge of the clock. The values are good on the SPI bus when sampled on the leading edge.

The modes in SPI_SETUP_SMP and SPI_SMPL_SETUP do not seem to allow that. It seems if one could do that - read/write on rising edge, the problem would be solved. The scope traces are details are in the prior posting.

Thanks for your help.

Regarsd,

Amit

Re: SPI data transfer issue

Posted: Thu Jul 21, 2011 10:50 am
by amaitra
This is the posting with all the info.

viewtopic.php?f=2&t=190&p=1161#p1161

I would appreciate any suggestions or thoughts you have,

Regards,

Amit

Re: SPI data transfer issue

Posted: Thu Jul 21, 2011 11:11 am
by xol
amaitra wrote: Clock Phase And Polarity: The LTC6802-2 SPI compatible
interface is configured to operate in a system using
CPHA = 1 and CPOL = 1. Consequently, data on SDI must
be stable during the rising edge of SCKI.

Data Transfers: Every byte consists of 8 bits. Bytes are
transferred with the most significant bit (MSB) first. On a
write, the data value on SDI is latched into the device on
the rising edge of SCKI (Figure 6). Similarly, on a read,
the data value output on SDO is valid during the rising
edge of SCKI
and transitions on the falling edge of SCKI
------------------------------------------
According to this you should use SUB-20 SPI master as SPI_SMPL_SETUP | SPI_CPOL_RISE
In this case SDI and SDO are sampled and valid on rising edge of the SCK.

Now let's take the traces you've attached.
Tell me exactly for the first trace what is expected and what do you get?
And how the SUB-20 SPI Master is configured?

Re: SPI data transfer issue

Posted: Thu Jul 21, 2011 12:38 pm
by amaitra
Let me see if I understand correctly.

SPI_SMPL_SETUP => write from sub-20 will be on trailing edge of sck. But as per the documentation - 6802-2 (slave) will READ on the leading edge. (wouldn't slave make errors on read?)

CPOL=1 the base value of the clock is one => SPI_CPOL_FALL?

http://en.wikipedia.org/wiki/Serial_Per ... erface_Bus

You still see that as the way to go?

In the attached trace:

SPI_ENABLE | SPI_CPOL_FALL | SPI_SETUP_SMPL | SPI_MSB_FIRST | SPI_CLK_1MHZ;

First cycle is 8 byte write:

out = 85 01 e0 00 00 00 75 9e (all hex)

Next activity: 2 byte write to read the above 6 bytes + 1 byte PEC

sub_spi_transfer(hd, out, in, 9, S_CONF(0, SS_LO))

out = 85, 02

I expect "in" to be above 6 bytes. That is the case on the SPI bus. But usb read is all 0's - sometimes sprinkle of ff's. The first 2 bytes which we are supposed to ignore is ff ff.

If I do the EXACT same transaction (write followed by read) with your suggestion - the input (in) is

ff ff e0 00 00 00 00 80 80 or
80 00 00 00 00 00 00 00

I do not have the logic analyzer connected right now. So I cannot tell you the SPI transaction. But that is what I see.

It is unpredictable - but seem to get stuck often at the second one i.e. next attempt it is the same.

Thanks in advance for your help.

Regards,

Amit

Re: SPI data transfer issue

Posted: Thu Jul 21, 2011 3:33 pm
by xol
Hi,
Once again.
1. You need to work in SPI_SMPL_SETUP | SPI_CPOL_RISE
2. I want to see oscilloscope diagram. And you must tell me what you get from SUB-20 in the case shown on diagram.

Re: SPI data transfer issue

Posted: Mon Jul 25, 2011 5:01 am
by amaitra
Hi there,

There was some issue with the connectivity. But the following config seems to work most reliably ...

SPI_ENABLE | SPI_CPOL_FALL | SPI_SETUP_SMPL | SPI_MSB_FIRST | SPI_CLK_1MHZ;

Could this work by "accident"?

Amit

Re: SPI data transfer issue

Posted: Mon Jul 25, 2011 6:02 am
by xol
No,
There is no "accident" in digital electronics.
If something works or does not work there should be an explanation.

Re: SPI data transfer issue

Posted: Mon Jul 25, 2011 7:05 am
by amaitra
I had grown up to believe that as well. The other thing about digital electronics - unless you really work at it and make sure, it does NOT work!

But the configuration you suggest and the one I try are sort of mirror images - and they BOTH work.

I am perfectly happy to use your suggestion, it will help if you can explain in a bit more detail.

e.g.. CPOL/CPHA = 1 (for LTC 6802-2) => base value of clock is 1. I read that to be high. So I was expected it to be SPI_CPOL_FALL instead of RISE as you suggest.

Similarly, the 6802 date sheet (which I had copied) seems to suggest, data read/write are on rising edge of clock.

The MOSI and MISO signals are usually stable (at their reception points) for the half cycle until the next clock transition.

So I realize, since 6802 will sample at rising edge, the sub-20 must write at the trailing edge - so the data is stable during read. But isn't that "cutting it close"?

I will appreciate some education. Both SPI and sub-20 behavior. Or perhaps explain why you suggest what you suggest based on the 6802 data sheet. I know your answer is "right" - but will help me understand things a bit better.
Also why both modes seem to work - I have tried with some amount of random data and both modes always work. It seems too much to be an accident.

Thanks in advance for your help.

Regards,

Amit

Re: SPI data transfer issue

Posted: Mon Jul 25, 2011 10:08 am
by xol
Hi. I can not help you more with it.
You have all required documentation and data sheets. We can not study IC's that all our customers work with. This is a job you have to do on your own. And we can not teach customers what is SPI or I2C e.t.c... There is a lot of information about it in the net.

If you have SPECIFIC question about SUB-20 please ask we will be happy to assist.