f18m

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!!

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

Hi Zador, 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

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 ...

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