LPSPI Shift Register Not Updating From TX Fifo

[SimonLyke]

Hi, ive currently got an SPI Slave setup using the teensy4-rs and imxrt-hal and im experiencing some behaviour in which i dont know if its expected behaviour or not.

My slave device will receive 2 bytes from the master device. once those 2 bytes have been clocked in, i enqueue a byte into the slaves TX FIFO hoping it will be moved to the shift register and then clocked out. however seemingly the shift register is not updating for the next time the clock is used.

i have made an example scope output for the behaviour im experiencing - the byte i enqueue comes out later than i expect it to

I need that byte to be clocked out on the next clock after being enqueued. im wondering what triggers the load of the shift register, or if i can trigger the shift register to load when i want it to.

Any help is greatly appreciated

Note: im forced to use spi mode 3 with phase and polarity set to 1. This is a limitation of the master and i have no control of this

[mciantyre]

imxrt-rs/imxrt-hal#159 demonstrates a similar example to

My slave device will receive 2 bytes from the master device. once those 2 bytes have been clocked in, i enqueue a byte into the slaves TX FIFO hoping it will be moved to the shift register and then clocked out.

In my example, the device receives two bytes from the controller. It adds them, then sends the sum back to the controller. The controller asserts that the received byte is correct. When I tested last week, that example was working as expected.

Without access to your code, I can't really say what's going on. You could try comparing your approach to my example to see if anything stands out.

[SimonLyke]

Hi, to be honest there isnt much difference at all in how your SPI slave is setup.

for reference mine is setup using the same iomuxc configuration with an ISR setup for falling edge on the chip select (but that ISR is triggered on a pin bridged with the CS pin)

SPI Setup

    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.p11, SPI_PIN_CONFIG);
    iomuxc::configure(&mut pins.p12, SPI_PIN_CONFIG);
    iomuxc::configure(&mut pins.p13, SPI_PIN_CONFIG);
    iomuxc::configure(&mut pins.p10, SPI_PIN_CONFIG);

    let mut spi = bsp::hal::lpspi::Lpspi::new(
        lpspi4,
        board::LpspiPins {
            sdo: pins.p11,
            sdi: pins.p12,
            sck: pins.p13,
            pcs0: pins.p10,
        },
    );
    spi.disabled(|spi: &mut bsp::hal::lpspi::Disabled<'_, 4>| {
        spi.set_mode(MODE_3);
        spi.set_watermark(Direction::Rx, 0);
        unsafe {
            let lpspi_rb = bsp::ral::lpspi::LPSPI4::instance();
            bsp::ral::modify_reg!(bsp::ral::lpspi, lpspi_rb, CFGR1, MASTER: false as u32);
        }
    });

    let mut fullduplex_transaction = Transaction::new(8).unwrap();
    fullduplex_transaction.receive_data_mask = false;
    fullduplex_transaction.transmit_data_mask = false;

    spi.enqueue_transaction(&fullduplex_transaction);

    unsafe {
        SPI = Some(spi);
    }

this is a portion of the ISR

#[bsp::rt::interrupt]
fn GPIO2_COMBINED_0_15() {
    unsafe {
        // take SPI driver
        let mut spi = SPI.take().expect("SPI DRIVER ALREADY TAKEN");
        let mut test_pin = TEST_PIN.take().expect("TEST_PIN ALREADY TAKEN");
        // loop whilst rx FIFO is empty and then get the command byte
        let lpspi4 = bsp::ral::lpspi::LPSPI4::instance();
        while bsp::ral::read_reg!(bsp::ral::lpspi, lpspi4, RSR, RXEMPTY) == 1 {}
        // let fifo1 = spi.fifo_status();
        let cmd = spi.read_data().unwrap() as u8;

// check cmd byte
        match cmd {
            READ => { // 0x3
                // loop whilst rx FIFO is empty
                while bsp::ral::read_reg!(bsp::ral::lpspi, lpspi4, RSR, RXEMPTY) == 1 {}
                // get addr low
                let addr_low = spi.read_data().unwrap() as u8;
                // loop whilst rx FIFO is empty
                while bsp::ral::read_reg!(bsp::ral::lpspi, lpspi4, RSR, RXEMPTY) == 1 {}
                // get addr high
                let addr_high = spi.read_data().unwrap() as u8;
                // enqueue first byte
                spi.enqueue_data(1 as u32); // This gets clocked out waaay too late
                // assert test pin so we know on the scope when the byte has been enqueued
                let _ = test_pin.set_high();
                // start sending data
                for x in 2..=11 {
                    spi.enqueue_data(x as u32);
                }
            }
        }
// ignore anything beyond, this is not the complete function

As shown here its a fairly simple example of using an SPI Slave. I just dont understand why the shift register is not updating with my enqueued byte and being clocked out.
Just before i enqueue the first byte, both FIFO's are empty. i then enqueue the byte and it doesnt get clocked out next time the clock runs.

If you have any ideas please let me know

[mciantyre]

Sorry, I won't be able to dig deep into your example. At the risk of pointing out the obvious: your device expects three bytes -- a command, a low address, and a high address -- before it replies to the controller. I was surprised to see this, given the context

My slave device will receive 2 bytes from the master device.

[SimonLyke]

Sorry my device is actually expecting 3 and is supposed to. this is why i didnt post the code in the first place ( forgot about this when i did ) the image in the question isnt actually completely representative of the scope output. i just made an example to show the timing of when a byte is enqueued and when it was clocked out.

so ignore the fact that my code is expecting 3 because in reality i am expecting 3 before i need to clock out a byte. i am getting 3 bytes successfully, then enqueueing a byte. this enqueued byte should then be clocked out immediately after but it is delayed. as the example scope output was supposed to explain.

sorry for the confusion

the problem still persists