SPI driver does not control csn signal

[plasticassius]

Since testing with spidev_test.c passes, I dug a bit deeper and found that my csn pin is stuck high. I checked the other csn pin and it is the same. Neither does it matter which entry in the /dev directory I use.

I've described this issue in nRF24/RF24#306

lsmod | grep spi
spi_bcm2835

ls -l /dev/spi*
crw-rw---- 1 root spi 153, 0 Nov 21 21:17 /dev/spidev0.0
crw-rw---- 1 root spi 153, 1 Nov 21 21:17 /dev/spidev0.1

cat /proc/cpuinfo
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7

Hardware : BCM2708
Revision : 000d
Serial :

uname -a
Linux raspberrypi 4.4.23+ #913 Tue Oct 4 13:56:56 BST 2016 armv6l GNU/Linux

The code that doesn't work:

struct spi_ioc_transfer tr;
memset(&tr, 0, sizeof(tr));
tr.tx_buf = (unsigned long)&tx;
tr.rx_buf = (unsigned long)&tx;
tr.len = sizeof(tr);
tr.speed_hz = this->speed,	
tr.delay_usecs = 0;
tr.bits_per_word = this->bits;
tr.cs_change = 1;

ret = ioctl(this->fd, SPI_IOC_MESSAGE(1), &tr);

If I manipulate the CS pin with gpiomem driver, then the above code works for nRF24 device.

[pelwell]

Why are you setting cs_change to 1? Although it can cause cs to change between segments of a single transfer, it has the opposite effect between transfers. See lthiery/SPI-Py#17 for another instance of the same error, and my explanation of what that flag really means.

Also:

tr.len = sizeof(tr);

looks wrong. sizeof(tx); would make more sense.

[plasticassius]

Excellent! Setting cs_change to 0 did the trick! Good catch with the tr.len = sizeof(tr) typo too.

[pelwell]

Are you happy to close this issue?

[plasticassius]

Absolutely, I just hadn't noticed the close issue button.