Subject: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external device; suspect conflict with onboard tri-radio module (MAYA-W27x)
Hi NXP team,
I'm trying to bring up an external SPI device (Waveshare 2-CH CAN HAT(https://www.waveshare.com/wiki/2-CH_CAN_HAT), dual MCP2515) on the FRDM-IMX93 board's EXPI 40-pin header (P11), using LPSPI3 (GPIO_IO08–11, matching the RPi-compatible pin positions). I've confirmed the HAT itself is fully functional (tested and working on a genuine Raspberry Pi with the standard dtoverlay=mcp2515 configuration).
Board / BSP:
- FRDM-IMX93, model NXP FRDM-IMX93
- NXP i.MX Release Distro 6.18-whinlatter, kernel 6.18.2-1.0.0-gf49f45233f7b
What I've configured (all verified correct at the device tree level):
- Overlay adds mcp2515@0/mcp2515@1 under &lpspi3, with cs-gpios = <&gpio2 8 1>, <&gpio2 7 1>; (GPIO_IO08/GPIO_IO07), matching the GPIO-based CS pattern I found in NXP's own upstream patch for a similar FRDM-IMX93 SPI3 peripheral (pixpaper display overlay).
- Extended &pinctrl_lpspi3 to mux GPIO_IO07 (CS1) as GPIO, since it was previously (MUX UNCLAIMED) in /sys/kernel/debug/pinctrl/.
- Disabled the pre-existing spidev0 node that was conflicting with CS0.
- Enabled reg_vexp_3v3/reg_vexp_5v (regulator-always-on) — these were disabled by default and the EXPI header had no power without this.
- Confirmed /dev/spidev2.0 is created and pinmux shows correct function assignment (lpspi3grp) on all 4 SPI pins.
Symptom:
- mcp251x driver always fails: spi2.0: Cannot initialize MCP2515. Wrong wiring? (err=19) and spi2.1: MCP251x didn't enter in conf mode after reset (err=110) — completely unchanged across every device-tree variation above.
- Raw SPI-level test with spidev_test (compatible lwn,bk4) on /dev/spidev2.0: RX buffer returns byte-for-byte identical data regardless of whether MOSI/MISO are physically shorted (loopback), left open, or bridged with a shunt. This suggests the SPI3 signals present at P11 header pins 19/21/23/24 are not being reflected in the controller's actual bus activity — i.e., the signals may not be reaching the header at all, or something else is interfering.
Suspected root cause:
Per UM12181 (FRDM-IMX93 Board User Manual, Section 2.11 "Tri-radio module interface"), the SPI3 signals (CLK, MOSI, MISO, CS0 — multiplexed on GPIO_IO08-11) are shared between the onboard MAYA-W27x tri-radio module and the M.2 connector, via a bidirectional 1.8V level translator (U729), resistor-selected. The document doesn't clarify whether/how the EXPI header (P11) is electrically isolated from this shared path when SPI3 alternate function is driven from the SoC side.
Question:
- Is P11's exposure of GPIO_IO08-11 electrically independent of the U729 translator/tri-radio path, or does using SPI3 on P11 require any additional configuration (e.g., disabling the tri-radio module, GPIO expander bits, or resistor rework) to route/isolate the signal to the header correctly?
- Is there a validated reference device tree (similar to imx93-11x11-evk-lpspi.dts for the EVK) for using LPSPI3 externally on the FRDM-IMX93 board specifically?
- Could a schematic excerpt for the SPI3/U729 signal path be shared to confirm the P11 connection topology?
Thanks in advance for your help.
FRDM-IMX93: No signal is output to the LPSPI3 (P11 EXPI header) SCK pin
Issue
I am trying to operate an external SPI device (2× MCP2515 CAN) using LPSPI3 (GPIO_IO08-11, spi@42550000) on the P11 EXPI header. The driver is active, and the peripheral appears to be running “internally,” but no signal is being output to the physical SCK pin (GPIO_IO11).
Evidence
The overlay is applied without errors; spi2.0/spi2.1 are registered in the SPI core.
Power, pinctrl, pinctrl-assert-gpios, cs-gpios, and clock source—all are correct and have been verified.
CS0 (same bank, GPIO alternate function, mode=0) works flawlessly—pulses are visible with both a multimeter and a logic analyzer.
SCK (mode=1, native LPSPI3_SCK) is completely flat/0V on the logic analyzer—whether the HAT is connected or not, it makes no difference in the continuous trigger loop.
Nevertheless, LPSPI3’s IRQ (GIC 97) is actually being triggered in /proc/interrupts (a single transfer attempt generated over 220 interrupts) — the peripheral’s internal logic (status/IER registers) is active.
Reading the LPSPI3 base address (0x42550000) with /dev/mem returns a “Bus error” — but flexcan2 (0x425b0000), which is running on the same bus, also returns the same error, meaning this is a general /dev/mem limitation, not specific to LPSPI3 (ruled out via the control group).
The DMA theory was tested and ruled out: when overriding dmas with an invalid phandle, the driver fell back to PIO with the message “dma setup error -19, use pio,” but the SCK signal still did not appear.
The `clk_ignore_unused` boot argument also made no difference.
Conclusion
The internal logic of the LPSPI3 peripheral is working (generating interrupts), but the SCK signal never reaches the external pin (GPIO_IO11)—while CS0 (GPIO mode) in the same pinctrl group outputs correctly, SCK (native LPSPI3 alternate function) does not. This appears to point to a configuration detail related to the pad driver/silicon or a configuration detail that NXP should be aware of, which cannot be explained by the device tree or software.
Question
On the FRDM-IMX93, is there an additional hardware/firmware enable step outside the device tree for LPSPI3_SCK (GPIO_IO11, native alternate function) via P11?
There is a known example where LPSPI3 works with the same pins on the i.MX93 EVK (community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ)—could there be a difference specific to the FRDM?
If anything is missing, I can add it.
root@imx93-11x11-lpddr4x-frdm:/sys/firmware/devicetree/base# ls
'#address-cells' clock-osc-24m firmware mcp2515_clock pmu regulator-hmisc-vddio regulator-vexp-3v3 soc@0 usbphynop2
'#size-cells' clock-osc-32k imx93-lpm memory psci regulator-usdhc2 regulator-vexp-5v sound-mqs usdhc3_pwrseq
__symbols__ compatible interrupt-controller@48000000 model regulator-adc-vref regulator-usdhc3 remoteproc-cm33 sw-keys
aliases cpus interrupt-parent mqs1 regulator-avdd regulator-vdd-12v reserved-memory thermal-zones
chosen display-subsystem ldb-display-controller mqs2 regulator-can2-stby regulator-vdd-5p0v secure-enclave timer
clock-ext1 ethosu ldb-phy name regulator-dvdd regulator-vddo serial-number usbphynop1
No, the imx93-11x11-frdm.dts file is the original; I edited the mcp2515-can-hat.dtbo overlay file, https://www.waveshare.com/wiki/2-CH_CAN_HAT, I only changed INT_1 from the default GPIO_25 to GPIO_24 (physical pin 18).
Hello @irfanktm
Hope you are doing very well.
Actually, there are a direct connections between the i.MX93 FRDM PADs and the P11 GPIO_IO08-IO11 Pines:
Could you please share steps to reproduce it by my side?
Best regards,
Salas.
Hello @irfanktm
I just made some test by my side:
SPI us working well in my i.MX93 FRDM.
I have the same environment as you.
One more question.
Do yo have voltage in your 3V3 and 5V pines of the i.MX93 FRDM board?
If not, please take a look to the below link to enable the regulators of the board:
Best regards,
Salas.
According to the logs, it makes me think you are trying to access to the SPI device over spidev_test, but the device is being handle by the MCP driver.
What I need to know is the entire device tree (.dts) that you are using, like:
Also, if you modified it, please let me know your modifications.
Also, I will try to get an mcp2515 CAN module to try the integration by my side.
Best regards,
Salas.
Please kindly share your entire device tree.
Or just the related to the lpspi3 node and pinmux.
Best regards,
Salas.
Yes, I have 3.3v and 5V at the p11 header,
Why I have errors?
imx93-11x11-lpddr4x-frdm login: root
root@imx93-11x11-lpddr4x-frdm:~# dmesg | grep -iE 'mcp251|lpspi3'
[ 8.989639] mcp251x: no symbol version for module_layout
[ 10.032864] mcp251x spi2.1: MCP251x didn't enter in conf mode after reset
[ 10.033021] mcp251x spi2.1: Probe failed, err=110
[ 10.033034] mcp251x spi2.1: probe with driver mcp251x failed with error -110
[ 10.074097] mcp251x spi2.0: Cannot initialize MCP2515. Wrong wiring?
[ 10.074256] mcp251x spi2.0: Probe failed, err=19
root@imx93-11x11-lpddr4x-frdm:~# ip link show
1: lo:
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:
link/ether 90:a9:f7:80:42:26 brd ff:ff:ff:ff:ff:ff
3: eth1:
link/ether 90:a9:f7:80:42:27 brd ff:ff:ff:ff:ff:ff
4: mlan0:
link/ether 80:a1:97:50:4e:0d brd ff:ff:ff:ff:ff:ff
5: uap0:
link/ether 82:a1:97:50:4f:0d brd ff:ff:ff:ff:ff:ff
6: wfd0:
link/ether 82:a1:97:50:4e:0d brd ff:ff:ff:ff:ff:ff
7: can0:
link/can
Technical Support Request — MCP2515 on i.MX93 LPSPI3
Multiple MCP2515 CAN controllers (3 units tested, 2 different manufacturers/boards, 8/16 MHz crystals) connected to an i.MX93-11X11-LPDDR4X-FRDM board via LPSPI3 (SPI2) intermittently fail to reach Configuration mode after reset (CANSTAT should read 0x80).
Environment: kernel 6.18.2 (NXP downstream), CONFIG_SPI_FSL_LPSPI built-in, ERR051608 prescale fix present. Device tree / pinctrl verified correct (LPSPI3 SIN/SOUT/SCK properly muxed, CS via cs-gpios). Logic-analyzer captures confirm MOSI/SCK/CS are generated correctly and consistently by the host.
Key observation:
- On a freshly opened spidev handle, the very first RESET + CANSTAT read succeeds (~0x80) roughly 50–60% of the time, with consistent ~2–6 ms timing.
- If additional RESET+read cycles are issued on the same, still-open SPI file descriptor, they consistently fail afterward, settling into a repeatable ~10–11 ms periodic pattern of fixed values (0x00 / 0xFF / 0xFB) that never reaches 0x80 again.
- This same failure signature is reproduced across all 3 physical MCP2515 units and 2 different board designs, ruling out a single defective chip/module.
- Adding inter-transfer delay (delay_usecs), a dummy 'flush' SPI transfer, and increasing the gap between cycles to 100 ms did not change the outcome (0/10 success once the pattern starts).
- VDD, GND, RESET pin and idle MISO level are all confirmed healthy (3.3 V) throughout.
- The mainline mcp251x kernel driver's own probe() shows the same instability: 5 consecutive bind attempts (unbind/clear driver_override/bind) all failed, alternating between err=-19 ("Wrong wiring?") and err=-110 ("didn't enter in conf mode after reset") in a regular, non-random pattern.
This pattern (good on first transfer after open, then a fixed repeatable failure signature on subsequent transfers within the same session — reproduced by the kernel driver's own probe as well) suggests a state that is not being fully cleared between consecutive LPSPI3 transfers/CS cycles, rather than a defect in the MCP2515 units themselves.
Question for NXP: is this consistent with a known LPSPI3 (i.MX93) behavior — e.g. FIFO/CS state not resetting cleanly between back-to-back transfers on the same SPI file descriptor — and is there a recommended driver-level workaround (e.g. required delay, FIFO flush, or CS handling) beyond ERR051608?
Technical Support Request
MCP2515 (Microchip) SPI communication failure on i.MX93 (NXP) SPI2/LPSPI3
1. Summary
Two MCP2515 CAN controllers (Waveshare 2-CH CAN HAT, MCP2515-I/SO, 16 MHz crystal) connected to an i.MX93-11X11-LPDDR4X-FRDM board via LPSPI3 (SPI2, CS0/CS1) never enter Configuration mode after power-up or SPI/hardware reset. All register reads return fixed, non-varying values instead of the expected CANSTAT = 0x80. The kernel mcp251x driver consistently reports probe failure (err=-110 "didn't enter in conf mode after reset", or err=-19 "Wrong wiring?").
2. Environment
- SoM/board: i.MX93-11X11-LPDDR4X-FRDM
- Kernel: 6.18.2-1.0.0-gf49f45233f7b (NXP downstream), CONFIG_SPI_FSL_LPSPI=y (built-in), ERR051608 prescale fix already present
- SPI bus: LPSPI3 (spi@42550000), 2 chip selects, custom device tree overlay (16 MHz fixed-clock, IRQ GPIO3-23 / GPIO3-24)
- CAN modules: Waveshare 2-CH CAN HAT, MCP2515-I/SO, marking "E3 2335BK5" (genuine Microchip marking format)
- Driver: mcp251x (mainline), tested against kernel driver and a custom spidev-based test utility
3. Troubleshooting performed
- Corrected device tree overlay target (&spi1/&lpspi3 vs. incorrect &spi2 label) — overlay now applies correctly, mcp2515 child nodes present in live DT
- Verified LPSPI3 pinctrl, cs-gpios, interrupt-parent/GPIO mapping against running device tree — all correct
- Verified master-side SPI signal integrity with a logic analyzer: MOSI, SCK and CS are generated correctly and consistently by the i.MX93 in several captures
- Confirmed VDD = 3.3V and idle MISO = 3.3V on both CAN modules (no short to GND)
- Confirmed RESET pin (pin 17, SOIC-18) = 3.3V (inactive) on both modules
- Tested SPI Mode 0,0 and Mode 1,1 (CPOL/CPHA), 100 kHz-8 MHz clock — no change in behavior
- Added 10k pull-up resistors on CS0/CS1 to resolve MISO bus contention between the two parallel MCP2515 devices — this stabilized (but did not correct) the readback data
- Custom spidev test tool: RESET instruction + immediate/continuous CANSTAT polling (1 ms interval, 300 ms window) after reset — CANSTAT settles instantly to a fixed value and never reaches 0x80
- Forced WRITE to CANCTRL (0x80) followed by READ — readback is unaffected by the write, indicating the SPI transaction is not being processed by the CAN controller logic
4. Key observation
CS0 device: CANSTAT/CANCTRL/all registers consistently read back 0x00 (100% repeatable across dozens of reset+read cycles, independent of register address, SPI mode, or written value).
CS1 device: CANSTAT/CANCTRL/all registers consistently read back 0xFF (100% repeatable, MISO never toggles during the transaction).
Both devices show clean, correctly-timed MOSI/SCK/CS from the master, but return a fixed value regardless of instruction, address, or CS pull configuration — this pattern is not explained by SPI mode/timing/wiring on the host side and is consistent with the MCP2515 CAN core never leaving its post-reset/oscillator-not-stable state.
5. Request
Given the host-side SPI signaling has been verified correct by logic analyzer and the device tree / kernel driver configuration is confirmed correct, we would like guidance on:
- Whether this failure signature (fixed register readback, CANSTAT never = 0x80) is consistent with a known MCP2515 crystal/oscillator start-up issue, and recommended oscilloscope/verification procedure for OSC1/OSC2
- Whether there are known compatibility issues between MCP2515 and i.MX93 LPSPI (beyond ERR051608, already addressed)
- Recommended next diagnostic steps or RMA process if a hardware defect in the MCP2515 modules is suspected
Please let us know if additional logic analyzer captures, device tree files, or kernel logs would help.
MCP2515 / i.MX93 LPSPI3 — Root-Cause Update
Follow-up to our earlier report. A new, isolating test now points away from the MCP2515 modules entirely and toward the i.MX93 LPSPI3 SPI controller / driver.
Test performed:
Using a userspace spidev tool, we repeatedly issue RESET + CANSTAT-read cycles on LPSPI3 (500 kHz, Mode 0) while varying only the physical state of the MISO line:
- MISO wired to a real MCP2515 chip: unstable, rarely reaches the expected 0x80.
- MISO physically disconnected (floating, no chip attached): a structured, repeating byte pattern (0x00 / 0xFF / 0xFB) still appears, with ~10–11 ms periodicity.
- MISO tied to GND through a 10kΩ resistor: the same repeating pattern still appears, essentially unchanged.
- MISO shorted directly to GND (~0Ω): the pattern disappears completely — reads become a flat, constant 0x00.
Key finding:
The exact same byte sequence, with millisecond-for-millisecond identical timing, reappears across independent runs (different process IDs, different times) and across different physical MISO conditions (disconnected vs. 10kΩ pulldown vs. connected to a real chip). The SPI ioctl() call itself returns success (no error) every time — this is not a failed transfer being masked; real data is being clocked in on every call.
Interpretation:
A genuinely floating or resistor-loaded input pin should not reproduce an identical, host-independent bit pattern down to the millisecond across separate process invocations. This level of determinism suggests the byte values being read back are not representative of the actual MCP2515 SO/MISO line, but are instead coming from a fixed, repeatable internal state of the LPSPI3 peripheral or its Linux driver (e.g., stale RX FIFO content, or a fixed pattern read regardless of the input pin's real logic level) — only a hard short to GND overrides it.
Question for NXP: could LPSPI3 (or its Linux driver, spi-fsl-lpspi) under certain conditions return fixed/stale RX FIFO content instead of the pin's real sampled value? Is there a known erratum or driver behavior that would explain a deterministic, wiring-independent readback pattern like this?
Hello dear @irfanktm
Please take a look to the post I made for your case:
There is explained how you can use the 2-Channel CAN HAT in our BSP and i.MX93 FRDM.
Best regards,
Salas.