SPI data transfer issue

[guslik]

Bocdan, Xol, is any evidence of success? I found, that discussion was terminated in Nov. 2010, does it mean, that solution is found ?

Thank you

[xol]

HI,
We did not get any information form Bocdan, so I assume he has found a problem in his code.

[amaitra]

Hello,

I am trying to access a Linear Semiconductor LTC6802-3 device over the SPI interface. I used the xdimax dongle for this. The platform used is Windows XP.

The xdimax device enumerates ok (over USB) and I can read/write the SPI configuration registers ok.

However, I am unable to read/write any 6802 registers. It seems the SPI interface is set up ok. Things are also wired up ok (as far we know).

I am trying the WRCFG and RDCFG commands to get started. I am using the broadcast mode - so no device address is involved (though it will be needed in later stages).

So it is write/read configuration group.

As per the 6802-2 documentation:

Write Configuration Registers (Broadcast Command)
1. Pull CSBI low
2. Send WRCFG command byte
3. Send CFGR0 byte, then CFGR1, CFGR2, … CFGR5 (All devices on bus receive same data)
4. Pull CSBI high; data latched into all devices on rising edge of CSBI

This should basically translate to (after sub_spi_config())

sub_spi_transfer(handle, out, NULL, 7, SS_LO)

so CSBI (SS_0) is pulled low and then the write happens and then pulled high.

The device is expecting MSB first. So in the c language array out[0] is the command (0x01), out[1] is CFGR0, out[2] is CFGR1 and so on. And length is 7.

The call to the API succeeds - but I have no simple way to know if the write actually happened. (It is necessary to set the configuration register correctly to make the rest of the things meaningful.)

One way is to read it back. The outlines procedure (for a different register is as follows):

Read Cell Voltage Registers (Address Command)
1. Pull CSBI low
2. Send Address byte for bottom device
3. Send RDCV command byte
4. Read CVR00 byte of bottom device, then CVR01 (B), CVR02 (B), … CVR17 (B), and then PEC (B)
5. Pull CSBI high
6. Repeat steps 1-5 for middle device and top device

In my case, it is a broadcast command for now.

So it should be

Read CFGn Registers
1. Pull CSBI low
2. Send RDCFG command byte
4. Read CFG0 byte, then CFG1, .... CFG6, and then the PEC
5. Pull CSBI high

So in effect SS_0 is pulled low (the chip select), then the RDCFG command is written and the device is expected to output the CFG registers which should be read in.

How do I achieve that?

Will this need 2 calls to sub_spi_transfer? One to write the command and the other to read in the output? The reading will be very "late" in that case.

If I do out and in in the same API => the out must FIRST complete and then the in (output of 6802-2) must be done. It is 1 byte output followed by 7 byte input - 6 CFGR registers and 1 PEC (checksum).
What should the length in the sub_api_transfer() be? Besides how do ensure the write is completed first before the read is done?

In any method - calling API once or twice - the APIs always succeed (return 0) - but the values read are also all 0's. And I have tried writing many different values - so it is always the same.

Any thoughts on what to do? Or what the problem might be? I have never used the XDIMAX dongle before. LTC has a 590 board doing a similar conversion (USB->SPI) but has lots of internal magic stuff not exposed to the outside world.

Any help or suggestions will be really appreciated.

Regards,

Amit

[xol]

HI,
To be short. In SPI there is no WRITE and READ. SPI master is doing both READ and WRITE at the same time. It shifts out data to MOSI and shifts in data from MISO at each SCK clock.
So if you need let's say "WRITE" 1 byte and after that "READ" 8 bytes you have to run 1+8 = 9 bytes SPI transaction.
Output data shoul have first byte - the byte you want to "WRITE" and rest 8 bytes don't care (usually 0x00 or 0xFF)
Input data will have first byte of unused data and 8 bytes of the data being "READ"
All the rest should be done according to data sheets of your IC and SUB-20.

[amaitra]

Thanks for your response.

I tried what you suggested - in fact I try reading in lot bigger amounts to see if the data has been late to be output.

Any other ideas?

Regards,

Amit

[xol]

HI,
You tried and what happens? What did you get and what is wrong with it?

In any case this type of interfaces should be debugged with digital oscilloscope. Connect it to SCK,MISO,MOSI,SS0 look at the signals level and make sure you are doing everything according to the specification of 6802-2. If you want us to help send us or post here oscilloscope diagrams.

Keep in mind that SUB-20 does not know what IC you are communicating with and what interface it requires. SUB-20 only does what you tell him to do. SO you have to be precise.

[amaitra]

Thanks,

I will try to get the scope traces for you.

As I mentioned in the initial mail, for getting started I am merely trying to write and then read a configuration register. I do not read back what I wrote.

I have no access to the 6802 registers - since this is the transport and that is not working. But I will instrument the 6802 and send you the traces.

From what you understand so far and perhaps what you know some of 6802, the following should work unless there is a h/w problem?

/* Set up the interface .... reading this back is good. */

int conf = SPI_ENABLE | SPI_CPOL_RISE|SPI_SMPL_SETUP|SPI_MSB_FIRST|SPI_CLK_1MHZ;

/* Write, then read it back. */
rc = sub_spi_config(fd, conf, 0);

unsigned char cfg[10] = { 0x85, 0x01, 0xE0, 0x00, 0x00, 0x00, 0x75, 0x9E }; /* 5 = device address (8 bytes valid only). */

(the first 2 bytes are address and command - 0x85, 0x01)

rc = sub_spi_transfer(fd, cfg, NULL, 8, SS_CONF(0, SS_LO));

/* now read it back. cfg/in are cleared to zero .*/

cfg[0] = 0x85;
cfg[1] = 0x02;

/* "write" cmd and read back output from 6802. */

rc = sub_spi_transfer(fd, cfg, in, 9, SS_CONF(0, SS_LO)); /* transition to high after the end. 6 CFG + PEC */

What I seem to read back - the first 2 bytes seems to be what I wrote - that is not what 6802 is supposed to output. And the rest is "junk" - although all ff;s or 0's as values are ok. Writing 7 is often read back as 3. Something to do with
stuck at bits, clock transitions?

Thanks in advance for your help.

Regards,

Amit

[xol]

HI,
As long as SUB-20 is doing what you ask him to do (and the best way to see it is oscilloscope trace) We could not help you too much as we are not so good familiar with the 6802 IC. SUB-20 works with a lot of different IC's and we definitely can not know operation details of each of them. This is what you have to do on your own.
So my suggestion is to take scope, open spec and go clock by clock and bit by bit verifying that you do it according to the spec.

[amaitra]

xol,

That is what we exactly did. Connect a scope and see the individual transaction bit by bit.

Summary: The writes to the 6802 are going ok. The command to output data also goes through ok. LTC6802-2 outputs the expected data on SPI (we are reading back what we wrote). But the output of the sub-20 dongle to the PC (via USB) is incorrect.

The 6802-2 read/writes data on the rising edge of the clock.

A relevant fact: (quote from the 6802 data sheet)

-----------------------------------------
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
(Figure 7).
---------------------------------------

So it seems, 6802-2 does read/write on the leading edge of the clock. It seems unusual for SPI as per our other reading but that is what it is.

The sub-20 SDK wants us do one of SPI_SETUP_SMPL or SPI_SMPL_SETUP.

To read data from 6802 one needs to write some address/cmd etc and then read the output.

So we were doing (command is 2 bytes, input is 6 bytes + PEC) = 2 + 9 +1 = 9 byte transaction.

sub_spi_transfer(hndl, cmd, in_buf, 9, SS_CONF(0,SS_LO));

The write goes through ok but the read is all garbled although the data on SPI bus is good - if we track it on the RISING edge.

I tried "splitting" the transaction into 2 parts - and change the config in between. i.e. write the command with SPI_SETUP_SMPL and change it to SPI_SMPL_SETUP before the read. But that does not work either.

My normal config is: MSB, clk high when idle, 1 Mhz. SS_0 is chip select.

SPI_ENABLE | SPI_CPOL_FALL | SPI_SETUP_SMPL | SPI_MSB_FIRST | SPI_CLK_1MHZ;

The application we are developing is expected to run for days on end.

Attached are the scope traces.

We are first "writing" the configuration registers.

The out = 85, 01, e0, 0,0,0, 75, 9e (all hex)

85, 01 is write config command followed by the data.

Then we read the same config register.

out = 85, 02

The in data we expect is the above given 6 bytes value + 1 byte PEC at the end.

We see that data correctly on the SPI bus. But the USB data is all wrong (on the PC) - even at a USB bus monitor application level. So the data received is wrong - not a problem with the library reading it.

So it seems to me - if we had a config where both the reads and write can happen on the rising edge of the clock we should be ok? Is it possible to do? Even a custom load of the software/firmware?

Thanks in advance for your help.

Regards,

Amit

[amaitra]

Some more quotes from the LTC6802-2 data sheet. When the data is being sampled for reading seems to be the key to be problem.

As mentioned, the data on the SPI bus is correct if we sample on the leading edge.

Thanks in advance for your help.

Regards,

Amit

-------------------
Data Link Layer
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
(Figure 7).
CSBI must remain low for the entire duration of a command
sequence, including between a command byte and
subsequent data. On a write command, data is latched in
on the rising edge of CSBI.
After a polling command has been entered, the SDO output
will immediately be driven by the polling state, with the
SCKI input ignored (Figure 8). See the Toggle Polling and
Level Polling sections.
------------------------------------------