In the DSPI Driver, a call to Init(..) will initialize the SPI almost as expected:
spi()->CR = LPSPI_CR_RST(1); // This statement causes the SPI to reset, Clock polarity and phase are set to 0.
The function returns with clock phase/polarity in 0/0. I then have to trigger the GPIO lines appropriately for the CS of devices on the board. Some of these devices require a clock polarity/phase of 1/1.
The call to Start(..) then appropriately sets the clock polarity/phase, but since the chip selects are already low, this causes a clock transition clocking in an extra bit.
my mitigation, for now, is to modify the DSPI Init function to set the polarity and phase appropriately after the spi()->CR = LPSPI_CR_RST(0);
Would this be considered a bug in the underlying OS?
SOMRT DSPI Driver clock phase and polarity using GPIO as CS
Re: SOMRT DSPI Driver clock phase and polarity using GPIO as CS
Hello ephogy,
With mutiple releases and many products with specific drivers, people will always need to know the nndk version and hardware platform to be able to help. I think that is why this has not had an answer and so many views.
With mutiple releases and many products with specific drivers, people will always need to know the nndk version and hardware platform to be able to help. I think that is why this has not had an answer and so many views.
Re: SOMRT DSPI Driver clock phase and polarity using GPIO as CS
Hi Tom
Sorry. This is with the most recent NNDK 3.57, SOMRT1061.
Sorry. This is with the most recent NNDK 3.57, SOMRT1061.
Re: SOMRT DSPI Driver clock phase and polarity using GPIO as CS
I think I am not understanding something in the original post, so please let me know. Wouldn't you only set the chip select after the configuration?
Re: SOMRT DSPI Driver clock phase and polarity using GPIO as CS
Does the example at \nburn\examples\SPI\PicKitSerialSPIDemoBd help at all? I don't know if it switches polarity.
Re: SOMRT DSPI Driver clock phase and polarity using GPIO as CS
I've opened a support ticket, but perhaps I can explain it here as well.
Part of this might be heritage related.
We use the four chip selects, and feed them into a demux to produce 16 outputs. We use this to talk to 12 SPI devices.
To operate this properly on the SOMRT1061, I can't use the chip select in the driver as the driver uses the ARM processor to drive the chip select. Unlike the coldfire which gave you the option of toggling all 4 CS for each transfer, the arm processor can only work with a single CS for any given transfer.
the DSPI driver gives the option to use CHIP_SELECT_DISABLED -- which I'm assuming was designed around this use case -- to drive GPIO lines as the Chip Select. The issue with this approach is that the Init function doesn't set the clock polarity (In fact it resets it to idle low). The Start function then properly assigns the clock polarity. The issue here is that if the clock polarity is high for one chip, then the init function will reset the polarity to low, I toggle the gpio lines, and then the start function sets the polarity high which clocks the first bit on the slave device.
Right now my temporary fix was to set the polarity in the init function, but I suppose I could simply add it before I set the gpio lines.
One possible work around for this that I could think of would be to implement a callback in the SPIModule to set gpio lines prior to the start of the spi transfer (and after completion), but after everything has been appropriately set, if that CHIP_SELECT_DISABLED option is used?
Part of this might be heritage related.
We use the four chip selects, and feed them into a demux to produce 16 outputs. We use this to talk to 12 SPI devices.
To operate this properly on the SOMRT1061, I can't use the chip select in the driver as the driver uses the ARM processor to drive the chip select. Unlike the coldfire which gave you the option of toggling all 4 CS for each transfer, the arm processor can only work with a single CS for any given transfer.
the DSPI driver gives the option to use CHIP_SELECT_DISABLED -- which I'm assuming was designed around this use case -- to drive GPIO lines as the Chip Select. The issue with this approach is that the Init function doesn't set the clock polarity (In fact it resets it to idle low). The Start function then properly assigns the clock polarity. The issue here is that if the clock polarity is high for one chip, then the init function will reset the polarity to low, I toggle the gpio lines, and then the start function sets the polarity high which clocks the first bit on the slave device.
Right now my temporary fix was to set the polarity in the init function, but I suppose I could simply add it before I set the gpio lines.
One possible work around for this that I could think of would be to implement a callback in the SPIModule to set gpio lines prior to the start of the spi transfer (and after completion), but after everything has been appropriately set, if that CHIP_SELECT_DISABLED option is used?