When cs_change is 1, there is no change in the waveform on the oscilloscope.
When using spi, there is no waveform change in the oscilloscope when cs_change is 1.
I have a thought. It looks like in the oscilliscope waveform that CS is being set to 1 (deselecting peripheral SPI device) after the 2 byte transfer is complete. That leads me to believe the signals are acting as expected. So it looks like the state of the pin is able to change. If you are sending two bytes, maybe try breaking up the two byte transfer into 1 byte transfers? Then that should gaurantee that CS changes back to 1 (deselecting device) after the first byte is sent.
If you are currently sending two bytes in one transfer, I think my suggestion will solve the problem. If I understand correctly.
Or you can indicate
SPI_IOC_MESSAGE(2)
to specify two transfers, which means CS will change after transfer 1, then reselect the device at the beginning of transfer 2.
@forumuser
Could you confirm chip_select is using Hardware or software in the device tree ?
If it is hardware chip select CS change cannot be controlled by software.
Also dump the device tree to check will be greate.
@ShaneCCC
With my experience, I have seen chip_select work with software. I had some bugs when I was writing my userspace SPI driver and was getting different results based on value of cs_change. I didn’t have logic analyzer to check though.
Extract the extracted_proc.dts file created with the command sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
dtc -I dts extraced_proc.dts -O dtb -o spi-rm-hw-cs.dtb After making spi-rm-hw-cs.dtb with this command
Can I specify /boot/spi-rm-hw-cs.dtb as FDT in extlinux.conf?