Support For LPSPI Slave Mode? (Teensy4.1)

[SimonLyke]

Hi, im developing a project that requires me to configure the Teensy4.1 as an SPI Slave. i managed to get this setup fairly easily and quickly when using an RP2040. But not using the Teensy4.1.

with the 'teensy4-bsp' and 'imxrt-hal' it seems as though Slave mode isnt supported since the only board::lpspi() function takes in a baudrate. and then just calls lpspi new in the imxrt-hal and temporarily disables the peripheral to change the clock.

i thought maybe i could just bypass this and call lpspi new without changing the clock. but then saw that the imxrt-hal prepares the pins but im unsure of what mode the peripheral chip select is being set to since for a slave device it needs to be an input.
i then noticed that the imxrt-hal calls init on the lpspi instance and then sets the master bit in the CFGR1 register.

There is also no method available to switch to slave mode when temporarily disabling the peripheral.

i am fairly new to embedded programming so please forgive me for any lack of knowledge. i have checked the register values and all seems to be set to what i would want it to be set to. and weirdly when i send data over spi to the Teensy, nothing clocks in. but when i remove tor insert he clock pin it seems to clock in a few empty bytes randomly, but leaving the pin connected doesnt clock anything in at all.

Is there actually support for slave mode? using either the hal or bsp since the IMXRT1060 supports slave mode with LPSPI but no high level support for it seemingly.

If so, could someone please point me in the right direction. or let me know if im going to have to do this on a much lower level somehow

For reference i am using LPSPI4 instance. and for the pins B0_00, B0_01, B0_02, B0_03. these all seem to be correct however as the pin sheet shows and the datasheet explains.

Thanks

[mciantyre]

Hey Simon. Today's imxrt-hal only supports using LPSPI peripheral as a controller. There's no support for using the LPSPI peripheral as a device.

That being said, it might not be too difficult to add LPSPI device support. mciantyre/imxrt-hal@fbc9589 is my quick experiment. The only driver addition is a method to enable device support. The rest of the commit introduces hardware examples and board support for the examples. I'm testing on two of my non-Teensy boards. See the commit message for more information.

Until there's a nicer API available, folks will need to use the LPSPI lower-level APIs to coordinate device I/O. rtic_spi_device.rs shows one way to do that. If you have contributions for better APIs, I'd be happy to consider them.

[SimonLyke]

When the read_data method returns None, the status register has the following flags set.
TRANSMIT_ERROR | FRAME_COMPLETE | TRANSMIT_DATA

when the read_data method returns a byte from the rx FIFO. the status register reads
TRANSMIT_ERROR | FRAME_COMPLETE | WORD_COMPLETE | TRANSMIT_DATA

if i clear the status register after each transaction, the transmit_error flag disappears. presumably its only there because i have txmask set in the TCR register

I just lowered the speed in which these byte transactions are being sent by the controller (not by lowering the baudrate but by adding a 500ms delay between each byte being sent). it seems as though the data is just being rejected by the rx FIFO on the peripheral teensy4.1 rather than being stored. What could cause this?

its almost as if the teensy4.1 is only allowing data to be clocked into the rx FIFO when the read_data() method is called or something. because i should not be getting different behaviour.

According to the datasheet, in slave mode the clock configuration register is not used. however am i supposed to be setting the prescale divisor or anything prior to setting up as an spi slave?. ive completely ignored clocks because of what the datasheet says but now im thinking maybe i was wrong.

[SimonLyke]

@mciantyre I have just noticed the bytes coming into the fifo are of the following bit pattern

1
11
111
1111
11111
111111
1111111
11111111

at no point is a low signal from the MOSI line being sampled. unsure of what could cause this behaviour. i would have thought that using the pin setup as you have or as shown in the demo example would provide us with the behaviour we want

    /// Create a new LPSPI driver from the RAL LPSPI instance and a set of pins.
    ///
    /// When this call returns, the LPSPI pins are configured for their function.
    /// The peripheral is enabled after reset. The LPSPI clock speed is unspecified.
    /// The mode is [`MODE_0`]. The sample point is [`SamplePoint::DelayedEdge`].
    pub fn new(lpspi: ral::lpspi::Instance<N>, mut pins: Pins<SDO, SDI, SCK, PCS0>) -> Self {
        //************************CUSTOM PIN SETUP FOR SPI SLAVE?********************************/
        use crate::iomuxc;
        const SPI_PIN_CONFIG: iomuxc::Config = iomuxc::Config::zero()
            .set_drive_strength(iomuxc::DriveStrength::R0_4)
            .set_open_drain(iomuxc::OpenDrain::Disabled)
            .set_hysteresis(iomuxc::Hysteresis::Disabled)
            .set_pull_keeper(None);

        iomuxc::configure(&mut pins.sdo, SPI_PIN_CONFIG);
        iomuxc::configure(&mut pins.sdi, SPI_PIN_CONFIG);
        iomuxc::configure(&mut pins.sck, SPI_PIN_CONFIG);
        iomuxc::configure(&mut pins.pcs0, SPI_PIN_CONFIG);

        lpspi::prepare(&mut pins.sdo);
        lpspi::prepare(&mut pins.sdi);
        lpspi::prepare(&mut pins.sck);
        lpspi::prepare(&mut pins.pcs0);
        Self::init(lpspi, pins)
    }
}

ive tried setting a pull down keeper on all spi pins apart from pcs. did not change behaviour.

dont really know whats causing this. il report back if i find anything else but if you have an idea please let me know

Note: all ive done is add the above code into the lpspi new function. and add the set_device_enable method as a trait impl of spi. just as you did in the demo example.
apart from that ive set spi up normally but without setting the baudrate since im acting as a slave. and then enqueued an rx transaction for 8 bytes and thats all ive done. if i have missed a part of the setup you did, let me know!

thanks

[SimonLyke]

SOLVED. i had issues with multiple things.

i cant explain why the data clocked in was just 1's being shifted into the FIFO. or why i would receive the pattern of 1,3,7,15 etc etc.

i found that removing the chip select line actually meant i was clocking in bytes properly. which led me to the problem of fixing the chip select line. (i assume this was because when i disconnected the PCS line it was being held low by default on the slave side, which caused the peripheral to start clocking in data).

oddly, the ground of the 2 devices was different despite being plugged into the same laptop because when the master asserted low, this did not work and the slave device did not see this as being asserted low. but when unplugging the pcs0 from the master it did detect it being low.

made a common ground by linking the devices ground pins together with a wire on the breadboard. this meant the chip select being asserted low was finally detected properly by the slave device.

the difficult thing to diagnose before was when i sent 0xFF to the slave device, only to have the slave device clock that in. it was only when i changed the bytes to be like 10101010 did i find that they werent clocked in properly.

This has been a learning curve for me. appreciate you pointing me towards the demo spi slave you had before. if not for that its possible it would have taken me much longer to setup the pins and disable the pullkeeper.

Thankyou

[mciantyre]

Great job, and thanks for following up to share your experience. I'll add a note in the imxrt-hal demos to describe a common ground for the hardware setup.

I'll eventually suggest an imxrt-hal commit to include the Lpspi::set_device_enable API, making it available to all users. I won't include pin configurations within the driver setup, like you did. Nevertheless, if you think it's helpful to include these pin configurations in teensy4-bsp (in here, for example), we could do that.

[SimonLyke]

thats okay, its important for me to document my findings. if anyone else runs down the same path i did, they might stumble across this.

however. i think maybe for configuring the pins. is it possible that once you construct an spi driver. if the Lpspi::set_device_enable is called, is it possible to configure the spi pins for the function of a spi slave here?

thankyou for adding a note on common ground as it might be important but this is likely just lack of experience in my part.

im now actually struggling to understand the DMA peripheral and its interactions with SPI using the HAL. is there a demo you could possible create or link me to that shows how i can use DMA to transfer u8's to a buffer from the SPI rx FIFO. as the spi.dma_read() method seems to construct a transaction for u32's and expects a buffer of u32's but this isnt realistic if the target frame size is 8 bits or something.

i would very much appreciate this as ive spent a good few hours today trying to understand how to get these to work on my teensy4.1

[canselcik]

I think I'm having this issue as well. CS stays high even though it was set to low if I enter wfi, and 0xFF are sent over MOSI. I tried all sorts of ways to initialize the pins and the lpspi but can't avoid it unless I skip the wfi.