Spurious CS high when using SPI enable_chip_select_0

[algesten]

I've been debugging an SPI problem for the last week, and in the end I ended up buying a logic analyzer to hunt the problem down.

The problem seems to stem from using enable_chip_select_0 instead of taking control over the CS myself.

I apologize in advance if the problem isn't in imxrt-hal, I've tried to follow the code, but I don't quite get how this specific feature works.

The code in question is this:

    let (_, _, _, spi4_builder) = p.spi.clock(
        &mut p.ccm.handle,
        ccm::spi::ClockSelect::Pll2,
        ccm::spi::PrescalarSelect::LPSPI_PODF_5,
    );

    let mut spi = spi4_builder.build(pins.p11, pins.p12, pins.p13);

    spi.set_clock_speed(bsp::hal::spi::ClockSpeed(1_000_000))
        .unwrap();

    spi.enable_chip_select_0(pins.p10);

    spi.set_mode(spi::MODE_0).unwrap();
    spi.clear_fifo();


// and later (using u16, since my chip uses that by default)

        let mut buf2 = [0x4100, 0];
        spi.transfer(&mut buf2)?;

Recording this with the logic analyzer I get this:

• White is CS
• Brown is clock
• Red is MOSI
• Orange is MISO

Notice how the white CS goes to high in between word 1 and word 2. I believe this not correct and the chip I'm working with (an IO-expander MCP23S17), does not like it at all.

The workaround is to take control over the CS myself, so quite easily solved once I saw the problem, but I wonder whether the behavior of method.enable_chip_select_0 can be fixed?

[mciantyre]

Thanks for the detailed report! These observations are consistent with how I've seen this SPI peripheral manage the chip select pin. Since the CS pin is fully managed by the hardware, changing the behavior requires us to study the reference manual, and understand what settings are available. It's definitely an imxrt-hal issue, so you're in the right place.

Besides driving CS manually, there might be two other options:

• Try using a u32 transfer with one value, instead of u16 transfers with two values. The timing diagram shows a CS transition in between two u16s. It does not show a CS transition in between the two u8s that comprise one u16. So if we we treat the transaction as a u32, we shouldn't see the CS transition. I'll guess that this is a workaround, but it may be easier to implement and test. A u32 implementation resembling this code might be all we need.

• Quick check through the reference manual reveals this field in the transmit command register:

  

  At a glance, this sounds like the real solution. But, I've not tried it. This might warrant a custom implementation for the embedded_hal::blocking::spi traits.

[mciantyre]

This should be resolved in imxrt-hal v0.5. The LPSPI driver now uses continuous transfers for blocking u8/u16/u32 exchanges and writes. Chip select remains asserted throughout the entire transfer.

The images below (click to expand) show logic analyzer recordings of the hal_spi example that exchanges this buffer

https://github.com/imxrt-rs/imxrt-hal/blob/4bee9504c533bec3c2e065a152973cef7f7df39c/examples/hal_spi.rs#L65

where Elem is one of

u8

u16

u32

[algesten]

Excellent! Thanks!