Closed algesten closed 1 year ago
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:
u32
transfer with one value, instead of u16
transfers with two values. The timing diagram shows a CS transition in between two u16
s. It does not show a CS transition in between the two u8
s 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.
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
where Elem
is one of
Excellent! Thanks!
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:
Recording this with the logic analyzer I get this:
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?