I’m testing the HW interfaces of iMX8 after flashing the Yocto linux image with BSP5
I noticed in the device tree that the current SPI interfaces use GPIO chip-select instead of the native cs
By modifying it to use the native chip-select to avoid the delays that comes with GPIO cs, I got the following:
The chip select’s behaviour seem like the clock instead of being stable 0 during the transfer period.
does the native chip-select work properly in the current SPI driver of BSP5?
I noticed in the device tree that the current SPI interfaces use GPIO chip-select instead of the native cs
Yes, that’s true. If native chip select is used, then it will toggle after transfer of each byte, which is not good for the most spi chips, because it means end of the transfer. That’s why we use GPIO chip-select.
The chip select’s behaviour seem like the clock instead of being stable 0 during the transfer period
Are you sure you measuring the chipselect and not data out?
Does the native chip-select work properly in the current SPI driver of BSP5?
Thank you for your answer. I made today SPI tests again, and noticed that SPI2 works properly when spi native chip select is used (in the test before there was a short between cs and clk as shown in picture above, sorry for that)
The new test:
[upload|LeNm8QYetOrB4LIRVe7EhGpiFZw=]
(yellow: SPI2_CS, blue: SPI2_CLK)
However the native chipselect for SPI1 toggles at each byte, although the device tree nodes for both SPIs are the same
and here is how it looks like:
[upload|m8URvFCLcoTbMFBU7LyhxvClm0Y=]
(red: SPI1_CS, green: SPI1_CLK)
is there anyway to make the cs in SPI1 like in SPI2 other than using GPIO cs?
(PS: with the default device tree the CS doesnt work automatically in both SPIs, where gpio cs is defined.
the only way to use gpio cs is to let a gpio manually go low and high in the program in every spi transfer)
