On Verdin board, setting SPI mode to 3, results in SPI mode 7

Technical Support
, ,
1

I am having an issue with the SPI mode. When I first start, reading it results in a 0, but if I set any bits in the mode, it also sets bit 2, so mode1 results in mode5, mode2, 6, and so on. If I set it to 0, it returns 0.

I am also getting some inconsistent things happening. I am in 16 bit mode. When I send to the device 0x7200, the MOSI should be sending LSB first, sometimes it sends the MSB first. Today, that is what it is doing. Yesterday, it was working fine, today it is not.

And I also found that if I used the same code somewhere else, it would error and give me an invalid parameter. I found that this is because the structure is not cleared.

But now I have the send working correctly using the transfer code from the example, but it is reading random values back, even though it is being sent 0s. I can see the signals and everything is correct. In fact at the moment, the values sent back on the read (second word), is always 0, which isn’t correct, but I should always report 0, but it’s not. Here is the transfer structure:
struct spi_ioc_transfer tr[1];

memset(&tr, 0, sizeof(tr));

tr[0].tx_buf = (__u64)tx;
tr[0].rx_buf = (__u64)rx,
tr[0].len = (uint32_t)len;
tr[0].speed_hz = m_speed;
tr[0].delay_usecs = m_delay;
tr[0].bits_per_word = m_bits;
tr[0].tx_nbits = 16;
tr[0].rx_nbits = 16;
tr[0].bits_per_word = 16;
tr[0].cs_change = false;

I have checked and rechecked the connections to the board. The all seem good. Does anyone have any suggestions as to get this working. I do have a level shifter as the device is 3.3 volts and the board is 1.8v. But that part is working correctly.

Thanks,
Steve

2

Hey @Evets,

A few questions…
Which Verdin SoM are you using?
Are you using one of our development carrier boards?
Also What OS are you using?
Are you using TorizonCore or BSP w/ yocto?

Can you tell us about your SPI set up a bit more? What tools/drivers are you using?

Thanks,

-Eric

3

@eric.tx
I tagged what I am using. imx8m Plus, verdin dev board v1.1, Torizon default with containers.
I am using the Torizon Linux driver, basically using the SPI example code (which has a flaw in it because the structure is not cleared). I am operating in mode 3 (but when I read it back, the mode is 7). The only time bit 4 is not set is what I set mode 0. Can you explain that?

Steve

4

TorizonCore 5 or TorizonCore 6?

And by SPI sample code you are referring to: spidev_test.c

via:

I’m looking to understand a bit more to see if i can recreate your issue.

-Eric

5

Yes, for my device it is a 16 bit device. It requires 2 reads, the first one sends the address, the second reads the data from the MISO input.

Thanks,
Steve

6

I wonder where do you apply “SPI mode” and what it is? I see no such thing neither in spidev_test arguments nor in SPI transfer structure. Your code snippet as well seems not using such setting. As well, how could it be 7 if there are only known modes 0 to 3, of course if we are talking about Microchip defined “SPI mode” term? AFAIK more standard than “mode” are CPOL+CPHA settings, which are supported by spidev_test.

What is LSB in this context? Least significant bit or byte? I guess you mean LSByte here . LSByte or MSByte depends on bits_per_word (spidev_test -b switch). Should be MSB for 8 bits per word and LSB for 16/32 bits per word.

With wrong cpol/cpha you may get not only random values, but in some cases it may work one day and fail another day unpredictably.

Regards

7

Hey @Evets,

Did @Edward’s response help you or are you still facing this issue?

-Eric

8

@eric.tx ,
Figured out my problem. The device I was reading from requires 2 separate read cycles, with the CS line deselecting it in between each read. I was doing 2 reads, but not deselecting the line.