spi_transceive stuck in lpspi_wait_tx_fifo_empty

[bobobo1618]

Hey folks,

I'm trying to write a driver for a new SPI device. I'm using the NXP FRDM_MCXN947 board and specifically, I'm using the Mikrobus header to communicate with an SPI device. My code is all here.

In particular, the DTS overlay is here and where the SPI read hangs is here.

I've tried a bunch of things but even the most basic SPI read is hanging so I'm not sure what else can be done.

Attaching a debugger shows that when the board is hanging, the backtrace looks like this:

Backtrace

(gdb) bt
#0  lpspi_wait_tx_fifo_empty (dev=0x1000c470 <__device_dts_ord_145>) at src/zephyr/drivers/spi/spi_nxp_lpspi/spi_nxp_lpspi.c:23
#1  transceive (dev=0x1000c470 <__device_dts_ord_145>, spi_cfg=0x30001810 <max30001_data_0+8>, tx_bufs=0x300028bc <z_main_stack+868>, rx_bufs=0x3000289c <z_main_stack+836>,
    asynchronous=asynchronous@entry=false, cb=cb@entry=0x0, userdata=userdata@entry=0x0) at src/zephyr/drivers/spi/spi_nxp_lpspi/spi_nxp_lpspi.c:272
#2  0x1000a7c0 in spi_mcux_transceive_sync (dev=<optimized out>, spi_cfg=<optimized out>, tx_bufs=<optimized out>, rx_bufs=<optimized out>)
    at src/zephyr/drivers/spi/spi_nxp_lpspi/spi_nxp_lpspi.c:287
#3  0x1000ac72 in z_impl_spi_transceive (rx_bufs=0x30002844 <z_main_stack+748>, tx_bufs=0x30002864 <z_main_stack+780>, config=<optimized out>, dev=<optimized out>)
    at src/zephyr/include/zephyr/drivers/spi.h:784
#4  spi_transceive (rx_bufs=0x30002844 <z_main_stack+748>, tx_bufs=0x30002864 <z_main_stack+780>, config=<optimized out>, dev=<optimized out>)
    at src/example-application/build/zephyr/include/generated/zephyr/syscalls/spi.h:38
#5  spi_transceive_dt (spec=<optimized out>, tx_bufs=tx_bufs@entry=0x300028bc <z_main_stack+868>, rx_bufs=rx_bufs@entry=0x3000289c <z_main_stack+836>)
    at src/zephyr/include/zephyr/drivers/spi.h:809
#6  0x1000506c in max30001_read_reg (dev=dev@entry=0x1000c4ac <__device_dts_ord_146>, reg=reg@entry=0 '\000', buf=buf@entry=0x30002908 <z_main_stack+944> "\310\027",
    buf_size=buf_size@entry=15) at src/example-application/drivers/sensor/max30001/max30001.c:130
#7  0x1000514a in max30001_init (dev=0x1000c4ac <__device_dts_ord_146>) at src/example-application/drivers/sensor/max30001/max30001.c:153
#8  0x1000bb26 in do_device_init (entry=entry@entry=0x1000c2c4 <__init___device_dts_ord_146>) at src/zephyr/kernel/init.c:311
#9  0x10006936 in z_sys_init_run_level (level=level@entry=INIT_LEVEL_POST_KERNEL) at src/zephyr/kernel/init.c:369
#10 0x10006a2e in bg_thread_main (unused1=<optimized out>, unused2=<optimized out>, unused3=<optimized out>) at src/zephyr/kernel/init.c:519
#11 0x10001d76 in z_thread_entry (entry=0x10006a21 <bg_thread_main>, p1=0x0, p2=0x0, p3=0x0) at src/zephyr/lib/os/thread_entry.c:48
#12 0x1000352a in arch_switch_to_main_thread (main_thread=0x0, stack_ptr=0x1 ")", _main=0x10006a21 <bg_thread_main>)
    at src/zephyr/arch/arm/core/cortex_m/thread.c:546
#13 0x00006600 in ?? ()

Is there something obvious I'm doing completely wrong or is the LPSPI driver on the MCXN947 just broken?

[bobobo1618]

I tried the same code on the lpcxpresso55s69 and it worked just fine so seems likely that it's an issue with the MCXN947 specifically.

[DerekSnell]

@bobobo1618 , @decsny is working on the LPSPI driver, and your issue seems related. @decsny, can you share if this is related to your on-going work?

[decsny]

MCXN947 is passing SPI testing on main, so driver should be basically functional, and other users reported a lot of their longstanding issues being fixed with the recent changes.

It could be a problem with the user app here or could be some edge case it exposes not handled properly by the driver, it's not clear to me yet. Maybe a signal trace can help here. And if the belief is that the driver is at fault then a minimum reproducible sample would be most useful.

[decsny]

Actually, I think I might have a guess of what is the issue, because I just noticed that flexcomm6 (which is used in user sample) does not have code to attach its clock in the frdm_mcxn947 board.c file, so maybe the issue is there is no clock to the LPSPI module.

[bobobo1618]

Actually, I think I might have a guess of what is the issue, because I just noticed that flexcomm6 (which is used in user sample) does not have code to attach its clock in the frdm_mcxn947 board.c file, so maybe the issue is there is no clock to the LPSPI module.

You're exactly right. I added it (followed the same pattern as flexcomm4) and the issue is gone.