I encountered an issue while using SPI with my Orange Pi 3 LTS, and now I'm going to share some solutions. Perhaps the Armbian Team can assist me in resolving the final problem.
These tests were conducted on Armbian 23.02.2 Bullseye with Linux 5.15.93-sunxi64.
The initial step I took to ensure the appearance of `spidev` on the Orange Pi 3 LTS was to include these configurations in `/boot/armbianEnv.txt`.
overlays=spi-spidev1
param_spidev_spi_bus=0
param_spidev_spi_cs=0
Note: If `spi-spidev` and `spi-spidev1` are added together, it will not work, and the `spidev` will not appear when using the `ls /dev/sp*` command.
After performing the above steps, I executed the `sudo reboot` command, and `/dev/spidev1.0` appeared.
root@orangepi3-lts:~/wiringOP# ls /dev/sp*
/dev/spidev1.0
However, this alone was insufficient to ensure proper functionality of SPI. I attempted to send a message to an ATMega 168p using a Python script that utilizes the `spidev` library.
The script is below:
import spidev
spi = spidev.SpiDev()
spi.open(1, 0)
spi.max_speed_hz=10000
payload = [0x0c, 0x00]
spi.xfer(payload)
print(*payload[1:])
The ATMega 168p occasionally received the message, and sometimes it did not. I suspected that the issue might be related to the MISO or MOSI connections. To investigate further, I directly connected the MISO pin of the Orange Pi 3 LTS to its MOSI pin, testing whether I would receive an echo in the script provided earlier. Indeed, I received the echo successfully.
Considering the observations so far, my remaining suspicion lies with the CS (Chip Select) line. If the CS line is not functioning properly, it may fail to select the specific device, resulting in issues with the request/response process (similar to what I experienced).
Hence, I proceeded to install wiringOp, on my device. This allowed me to read all the GPIOs of my Orange Pi 3 LTS and check for any anomalies. After successfully building it, I ran the command `gpio readall` and observed the following output:
root@orangepi3-lts:~/wiringOP# gpio readall
+------+-----+----------+------+---+ OPi 3 +---+------+----------+-----+------+
| GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO |
+------+-----+----------+------+---+----++----+---+------+----------+-----+------+
| | | 3.3V | | | 1 || 2 | | | 5V | | |
| 122 | 0 | SDA.0 | OFF | 0 | 3 || 4 | | | 5V | | |
| 121 | 1 | SCL.0 | OFF | 0 | 5 || 6 | | | GND | | |
| 118 | 2 | PWM.0 | OFF | 0 | 7 || 8 | 0 | OFF | PL02 | 3 | 354 |
| | | GND | | | 9 || 10 | 0 | OFF | PL03 | 4 | 355 |
| 120 | 5 | RXD.3 | OFF | 0 | 11 || 12 | 0 | OFF | PD18 | 6 | 114 |
| 119 | 7 | TXD.3 | OFF | 0 | 13 || 14 | | | GND | | |
| 362 | 8 | PL10 | OFF | 0 | 15 || 16 | 0 | OFF | PD15 | 9 | 111 |
| | | 3.3V | | | 17 || 18 | 0 | OFF | PD16 | 10 | 112 |
| 229 | 11 | MOSI.1 | ALT2 | 0 | 19 || 20 | | | GND | | |
| 230 | 12 | MISO.1 | ALT2 | 0 | 21 || 22 | 0 | OFF | PD21 | 13 | 117 |
| 228 | 14 | SCLK.1 | ALT2 | 0 | 23 || 24 | 0 | OFF | CE.1 | 15 | 227 |
| | | GND | | | 25 || 26 | 0 | OFF | PL08 | 16 | 360 |
+------+-----+----------+------+---+----++----+---+------+----------+-----+------+
| GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO |
+------+-----+----------+------+---+ OPi 3 +---+------+----------+-----+------+
I noticed that the CS pin (GPIO 227) is currently set to `OFF` and needs to be configured as `ALT2` along with `MOSI.1`, `MISO.1`, and `SCLK.1` . This information gave me a clear direction on how to solve my problem. To investigate further, I began checking the device tree configuration using the following commands: `sudo armbian-config` -> `System` -> `Dtc`:
...
spi1-pins {
pins = "PH4\0PH5\0PH6";
function = "spi1";
phandle = <0x2b>;
};
spi1-cs-pin {
pins = "PH3";
function = "spi1";
phandle = <0x2c>;
};
...
spi@5011000 {
compatible = "allwinner,sun50i-h6-spi\0allwinner,sun8i-h3-spi";
reg = <0x5011000 0x1000>;
interrupts = <0x00 0x0b 0x04>;
clocks = <0x04 0x53 0x04 0x51>;
clock-names = "ahb\0mod";
dmas = <0x2a 0x17 0x2a 0x17>;
dma-names = "rx\0tx";
pinctrl-names = "default";
pinctrl-0 = <0x2b 0x2c>;
resets = <0x04 0x20>;
status = "disabled";
#address-cells = <0x01>;
#size-cells = <0x00>;
phandle = <0x72>;
};
...
Upon examining the pinout diagram, I realized that the Orange Pi 3 LTS utilizes SPI1, and all the SPI pins (H3, H4, H5, H6) were correctly configured in the device tree. This led me to speculate that the issue might not be in the device tree itself but rather in the `spi-spidev1 overlay`. To investigate further, I decompiled the `sun50i-h6-spi-spidev1.dtbo` file located at `/boot/dtb/allwinner/overlay/` into a `.dts` file using the command `dtc -I dtb -O dts sun50i-h6-spi-spidev1.dtbo -o sun50i-h6-sp i-spidev1.dts`. Next, I edited the `pinctrl-0` section of the `sun50i-h6-spi-spidev1.dts` file, adding the addresses `0x2b` and `0x2c` (similar to what was done in spi@5011000).
/dts-v1/;
/ {
compatible = "allwinner,sun8i-h3-spi";
fragment@0 {
target-path = "/aliases";
__overlay__ {
spi1 = "/soc/spi@5011000";
};
};
fragment@1 {
target = <0xffffffff>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <0x2b 0x2c>;
status = "okay";
#address-cells = <0x01>;
#size-cells = <0x00>;
spidev@0 {
compatible = "armbian,spi-dev";
reg = <0x00>;
spi-max-frequency = <0xf4240>;
};
};
};
__fixups__ {
spi1 = "/fragment@1:target:0";
spi1_pins = "/fragment@1/__overlay__:pinctrl-0:0";
};
};
Compiled the modified `sun50i-h6-spi-spidev1.dts` file into a `.dtbo` using the command `dtc -O dtb -I dts sun50i-h6-spi-spidev1.dts -o sun50i-h6-spi-spidev1.dtbo`. Then, I rebooted the Orange Pi 3 LTS. After the reboot, I ran the `gpio readall` command again to check the GPIO pin status:
root@orangepi3-lts:~# gpio readall
+------+-----+----------+------+---+ OPi 3 +---+------+----------+-----+------+
| GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO |
+------+-----+----------+------+---+----++----+---+------+----------+-----+------+
| | | 3.3V | | | 1 || 2 | | | 5V | | |
| 122 | 0 | SDA.0 | OFF | 0 | 3 || 4 | | | 5V | | |
| 121 | 1 | SCL.0 | OFF | 0 | 5 || 6 | | | GND | | |
| 118 | 2 | PWM.0 | OFF | 0 | 7 || 8 | 0 | OFF | PL02 | 3 | 354 |
| | | GND | | | 9 || 10 | 0 | OFF | PL03 | 4 | 355 |
| 120 | 5 | RXD.3 | OFF | 0 | 11 || 12 | 0 | OFF | PD18 | 6 | 114 |
| 119 | 7 | TXD.3 | OFF | 0 | 13 || 14 | | | GND | | |
| 362 | 8 | PL10 | OFF | 0 | 15 || 16 | 0 | OFF | PD15 | 9 | 111 |
| | | 3.3V | | | 17 || 18 | 0 | OFF | PD16 | 10 | 112 |
| 229 | 11 | MOSI.1 | ALT2 | 0 | 19 || 20 | | | GND | | |
| 230 | 12 | MISO.1 | ALT2 | 0 | 21 || 22 | 0 | OFF | PD21 | 13 | 117 |
| 228 | 14 | SCLK.1 | ALT2 | 0 | 23 || 24 | 0 | ALT2 | CE.1 | 15 | 227 |
| | | GND | | | 25 || 26 | 0 | OFF | PL08 | 16 | 360 |
+------+-----+----------+------+---+----++----+---+------+----------+-----+------+
| GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO |
+------+-----+----------+------+---+ OPi 3 +---+------+----------+-----+------+
The SPI functionality is now operational, but this solution is not definitive. To address the underlying issue, I need assistance as device trees, kernels, and other aspects of Linux are not within my area of expertise. It seems that the problem with the CS pin is related to an error during the boot process, resulting in an incorrect address assignment.
Well, I hope this information proves helpful to others who are experiencing the same issue as I did.
Remember: English is not my first language, so there may be some errors.
