Problem with SPI on Lime2

[f18m]

Hi all,

first of all, I'm new to this forum even if I've been using Armbian on my Olimex Lime2 since lot of time and I find it a great project; thanks and keep up the good work!

 

Now: I would like to use the Lime2 SPI #2 on pins "b" in master mode to communicate with a single slave device. 

What I did was:

 1) downloaded Armbian v5.31 (latest available release at the time I write)

 2) following the guide at https://docs.armbian.com/User-Guide_Allwinner_overlays/  I modified /boot/armbianEnv.txt to contain:

verbosity=1
logo=disabled
console=both
disp_mode=1920x1080p60
overlay_prefix=sun7i-a20
rootdev=UUID=8cf9ed72-8225-4db8-a3a2-a242d648d644
rootfstype=ext4
overlays=spi-spidev
param_spidev_spi_bus=2
param_spi2_bus_pins=b

and rebooted.

3) at reboot I found that a device /dev/spidev32766.0 does actually exist now (good!); it was not there before.

 

PROBLEM: I tried to use different example code found online to use that SPI device but the oscilloscope reveals that the clock line (pin PB15 when using SPI2 on pins b ) never show any activity (always low) as all other lines (CS0 and MOSI). So I guess I must be doing something wrong... any ideas or suggestions? Is there some message or log where I can check that what I activated is indeed the SPI #2 and not another SPI ? Or maybe the "bus_pins" setting is not working properly and the SPI is activated on pins "a" ?

 

Btw to send data on the SPI I tried

 - the Python library provided by Olimex, https://pypi.python.org/pypi/pyA20Lime 

 - spidev_test utility, http://elixir.free-electrons.com/linux/v4.0/source/Documentation/spi/spidev_test.c

I tried sending data in an infinite loop and inspected the pins with an oscilloscope... but as I said: nothing, all lines seem to be always low (0V)

 

Thanks!

Francesco

[zador.blood.stained]

30 minutes ago, f18m said:

Is there some message or log where I can check that what I activated is indeed the SPI #2 and not another SPI ?

Serial console log from u-boot would be the first thing to check and post here. Spidev node name (/dev/spidev32766.0) looks suspicious because it should be /dev/spidev2.0, so it's possible that there is a typo or some other problem that affects both pinmux and alias.

[f18m]

3 minutes ago, zador.blood.stained said:

Serial console log from u-boot would be the first thing to check and post here. Spidev node name (/dev/spidev32766.0) looks suspicious because it should be /dev/spidev2.0, so it's possible that there is a typo or some other problem that affects both pinmux and alias.

Thanks for fast reply! Unfortunately I don't have right now an FTDI converter to quickly attach to the Lime2 UART that is mapped to serial console... is it possible to collect that serial console log from somewhere else (ask uboot to save it in RAM somewhere?)?

Indeed the name of the SPI is "strange" but in some other threads I saw that explained by the fact that udev is involved in the process... not sure. 

Btw the same suspicious name of the SPI is generated also when I put "param_spidev_spi_bus=1" in armbianEnv.txt ... 

 

 

[zador.blood.stained]

3 hours ago, f18m said:

is it possible to collect that serial console log from somewhere else (ask uboot to save it in RAM somewhere?)?

AFAIK no

 

3 hours ago, f18m said:

Indeed the name of the SPI is "strange" but in some other threads I saw that explained by the fact that udev is involved in the process... not sure. 

Btw the same suspicious name of the SPI is generated also when I put "param_spidev_spi_bus=1" in armbianEnv.txt ... 

Yes, I just fixed an issue with aliases, and I just tested the latest version of the overlays and it should work according to this:

# cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins | grep spi2
pin 46 (PB14): 1c17000.spi (GPIO UNCLAIMED) function spi2 group PB14
pin 47 (PB15): 1c17000.spi (GPIO UNCLAIMED) function spi2 group PB15
pin 48 (PB16): 1c17000.spi (GPIO UNCLAIMED) function spi2 group PB16
pin 49 (PB17): 1c17000.spi (GPIO UNCLAIMED) function spi2 group PB17
# ls /dev/spi*
/dev/spidev2.0
#

 

So either waiting for a new stable release, building and installing a fresh kernel or grabbing prebuilt kernel and DT packages tomorrow from the beta repository should work.

Please note that you'll have to add "spi2" overlay as well:

overlays=spi2 spi-spidev
param_spidev_spi_bus=2
param_spi2_bus_pins=b

 

 

[f18m]

Hi Zador,

 

Quote

So either waiting for a new stable release, building and installing a fresh kernel or grabbing prebuilt kernel and DT packages tomorrow from the beta repository should work.

thanks for the fix; I switched today to nightly builds and I tested again (adding also "spi2" to list of overlays) and the /dev/spidev2.0 appeared after reboot!

tomorrow I will test with the oscilloscope

 

Thanks,

F

 

 

[f18m]

hi,

today I tested the /dev/spidev2.0 device with the oscilloscope and found it is working now!!

 

My only problem now is that apparently the SPI_SS (slave select) signal is always low and goes high when transmitting. AFAICS from the A20 user manual (http://dl.linux-sunxi.org/A20/A20 User Manual 2013-03-22.pdf) I would expect instead the opposite: the signal should be normally high and then go low when transmitting.

My slave expects the latter behaviour: SS low when transmitting.

 

Do you think it is possible to achieve this behavior? Otherwise can I have the SPI#2 enabled but use the SS as GPIO ?

 

thanks a lot!

Francesco

 

 

[zador.blood.stained]

Chip select should be active low by default. Are you sure you are not setting SPI_CS_HIGH for the SPI mode?

[f18m]

On 9/10/2017 at 8:20 PM, zador.blood.stained said:

Chip select should be active low by default. Are you sure you are not setting SPI_CS_HIGH for the SPI mode?

I verified and I'm not using SPI_CS_HIGH.... however I realized that the spike going high was not at the beginning of the transmission: it was AFTER the SCK signal stops clocking, so I realized that my problem was a missing pull-up on the slave-select/chip-select signal. I put there a resistor as pull up and now I have a good signal!

 

Thank you so much for your help!!