f18m Posted October 7, 2017 Share Posted October 7, 2017 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 Link to comment Share on other sites More sharing options...
zador.blood.stained Posted October 7, 2017 Share Posted October 7, 2017 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. Link to comment Share on other sites More sharing options...
f18m Posted October 7, 2017 Author Share Posted October 7, 2017 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 ... Link to comment Share on other sites More sharing options...
zador.blood.stained Posted October 7, 2017 Share Posted October 7, 2017 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 Link to comment Share on other sites More sharing options...
f18m Posted October 8, 2017 Author Share Posted October 8, 2017 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 Link to comment Share on other sites More sharing options...
f18m Posted October 9, 2017 Author Share Posted October 9, 2017 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 Link to comment Share on other sites More sharing options...
zador.blood.stained Posted October 9, 2017 Share Posted October 9, 2017 Chip select should be active low by default. Are you sure you are not setting SPI_CS_HIGH for the SPI mode? Link to comment Share on other sites More sharing options...
f18m Posted October 11, 2017 Author Share Posted October 11, 2017 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!! Link to comment Share on other sites More sharing options...
Recommended Posts