Closed heeplr closed 1 month ago
There's something strange about your overlay, or perhaps some other software is changing the pinmux. When I load sc16is752-spi1
I get:
pi@phil-pi5:~ $ pinctrl 18-21
18: op dl pd | lo // GPIO18 = output
19: a0 pd | lo // GPIO19 = SPI1_MISO
20: a0 pd | lo // GPIO20 = SPI1_MOSI
21: a0 pd | lo // GPIO21 = SPI1_SCLK
This is correct - the CS line is driven as a GPIO by the kernel SPI framework. I get the same result whether the overlay is loaded by the firmware or at runtime using the dtoverlay
command.
Try this:
dtoverlay=sc16is752-spi1
in config.txt.pinctrl 18-21
show?sudo dtoverlay sc16is752-spi1
.pinctrl 18-21
show now?The results are strange indeed:
$ ls /dev/ttySC*
ls: cannot access '/dev/ttySC*': No such file or directory
$ pinctrl 18-21
18: a0 pd | hi // GPIO18 = SPI1_CE0
19: no pd | -- // GPIO19 = none
20: no pd | -- // GPIO20 = none
21: no pd | -- // GPIO21 = none
$ sudo dtoverlay sc16is752-spi1
$ ls /dev/ttySC*
/dev/ttySC0 /dev/ttySC1
$ pinctrl 18-21
18: op dh pd | hi // GPIO18 = output
19: a0 pd | lo // GPIO19 = SPI1_MISO
20: a0 pd | lo // GPIO20 = SPI1_MOSI
21: a0 pd | lo // GPIO21 = SPI1_SCLK
The sc16is752-spi1-overlay.dts from 29f7f01091 i'm using is
dts-v1/;
/plugin/;
/ {
compatible = "brcm,bcm2835";
fragment@0 {
target = <&gpio>;
__overlay__ {
spi1_pins: spi1_pins {
brcm,pins = <19 20 21>;
brcm,function = <3>; /* alt4 */
};
spi1_cs_pins: spi1_cs_pins {
brcm,pins = <18>;
brcm,function = <1>; /* output */
};
int_pins: int_pins@18 {
brcm,pins = <24>;
brcm,function = <0>; /* in */
brcm,pull = <0>; /* none */
};
};
};
fragment@1 {
target = <&spi1>;
__overlay__ {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins &spi1_cs_pins>;
cs-gpios = <&gpio 18 1>;
status = "okay";
sc16is752: sc16is752@0 {
compatible = "nxp,sc16is752";
reg = <0>; /* CE0 */
clocks = <&sc16is752_clk>;
interrupt-parent = <&gpio>;
interrupts = <24 2>; /* IRQ_TYPE_EDGE_FALLING */
pinctrl-0 = <&int_pins>;
pinctrl-names = "default";
gpio-controller;
#gpio-cells = <2>;
spi-max-frequency = <4000000>;
};
};
};
fragment@2 {
target = <&aux>;
__overlay__ {
status = "okay";
};
};
fragment@3 {
target-path = "/";
__overlay__ {
sc16is752_clk: sc16is752_spi1_0_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <14745600>;
};
};
};
__overrides__ {
int_pin = <&sc16is752>,"interrupts:0", <&int_pins>,"brcm,pins:0",
<&int_pins>,"reg:0";
xtal = <&sc16is752_clk>,"clock-frequency:0";
};
};
You must have a script etc. that is changing the pinmux for GPIO 18, perhaps using pinctrl. If the pin had been changed from Device Tree then the overlay would not have applied successfully at runtime.
Indeed I can't reproduce this with a fresh image. That's strange since this is basically just vanilla raspbian-lite + custom realtime kernel. I'll close this. If it really affects other's too, it could be reopened.
@pelwell thanks for clarifying
Describe the bug
On RPi5 with
Linux mypi 6.6.31+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-29) aarch64 GNU/Linux
and also customLinux mypi 6.6.45-rt39-v8-16k+ #11 SMP Sat Aug 31 13:38:16 BST 2024 aarch64 GNU/Linux
, the configured CS (in my case CS0 of SPI.0 and SPI.1) is pulled high after $wordlength clock cycles. It seems that earlier kernels/Pi models didn't show this behaviour.Steps to reproduce the behaviour
Reads from peripherals like the ICM42605 IMU or the SC16IS752 UART won't work if CS is pulled high before reading an answer. (I'll use SC16IS752 on SPI1 as example, but also happens on SPI0):
dtoverlay=sc16is752-spi1
/dev/ttySC0
and/dev/ttySC1
existecho 1 > /dev/ttySC0
sc16is7xx spi1.0: chip reports 255 free bytes in TX fifo, but it only has 64
pinctrl set 18 op
echo 1 > /dev/ttySC0
and everything works as expectedconnecting a logic analyzer shows the effect with an ICM42605: D0 - SCLK D1 = MISO D2 = MOSI D3 = CS
works
doesn't work
Device (s)
Raspberry Pi 5
System
Logs
No response
Additional context
No response