TI E2E Community
Automatic SPI Chip select generation
In the SPI examples for starterware there is a manual assert deassert of the SPI chip select. However, from the manual I've come to understand that it is possible to make this generation automatic, so that I don't have to care about it, however I can not find anywhere any kind of information that is straight forward on what has to be done.
"The chip select timing control is only available in master mode with automatic chip select generation (FORCE bit field is cleared to 0)" (under 184.108.40.206 Chip-Select Timing Control) is basically everything I can find on this subject. Does anybody know how to do this?
The assert and deassert APIs are used to keep the SPI chip selects (or the SPIEN as called) activated for the entire transfer, across multiple SPI words of the transfer. This kind of an operation is required with read/write from/to flash devices etc, where CS/SPIEN deassertion could mean change/end of commands.
Since, the SPI examples of the StarterWare package deal with the flash this feature is used.
If you don't require such an operation (of SPIEN/CS being active for the entire transfer), just don't use the assert/deassert APIs. The SPIEN/CS should toggle the moment SPI data registers are written to and depending on the timing configuration in the registers programmed.
Hope this helps.
Thanks and regards,
Thanks for your answer! Yes, that is the way I would like it to work, however it is not working. My test transmission basically looks like this (I would like to transmit AA):
/* Enable the McSPI channel for communication.*/ McSPIChannelEnable(SOC_SPI_1_REGS, chNum1); McSPIIntStatusClear(SOC_SPI_0_REGS, MCSPI_INT_TX_EMPTY(chNum0)); McSPITransmitData(SOC_SPI_1_REGS, 0xFFFFFFAA, chNum1); /* Disable the McSPI channel.*/ McSPIChannelDisable(SOC_SPI_1_REGS, chNum1);
When this is done no transmission is seen. However, if I run the assert-command before, and the deassert-command after, the transmission can be seen on my logic analyzer. So basically I am left to manually asserting and asserting the CS. There seems to be something I am missing, does anybody have any clues?
I think there is something with this..
Read this from the processor guide..
" Transfer Format With PHA = 0'
In the transfer format with PHA = 0, SPIEN is activated a half cycle of SPICLK ahead of the first SPICLK edge. In both master and slave modes, McSPI drives the data lines at the time of SPIEN is asserted" .........In master mode, the SPIEN line must be negated and reasserted between each successive SPI word. This is because the slave select pin freezes the data in its shift register and does not allow it to be altered if PHA bit equals 0.
"Transfer Format With PHA = 1"
In the transfer format with PHA = 1, SPIEN is activated a delay (tLead) ahead of the first SPICLK edge. In both master and slave modes, McSPI drives the data lines on the first SPICLK edge.
So you may have to chose MCSPI_CLK_MODE_1 in McSPIClkConfig() as against what is done in the application.
On another tangent, there is a mistake in your code snippet. You are using SPI_0_REGS for interrupt clearing
Unfortunately it seems like that did not help either =/ Fixing the code snippet gave no result either, but thanks :)
The setup codes for the interface that I'm currently use look like this:
/* Reset the McSPI instance.*/ McSPIReset(baseAdd);
/* Set polarity of SPIEN to low.*/ McSPICSPolarityConfig(baseAdd, MCSPI_CS_POL_LOW, channel);
/* Enable chip select pin.*/ McSPICSEnable(baseAdd); /* Enable master mode of operation.*/ McSPIMasterModeEnable(baseAdd); /* Perform the necessary configuration for master mode.*/ McSPIMasterModeConfig(baseAdd, MCSPI_SINGLE_CH, MCSPI_TX_RX_MODE, MCSPI_DATA_LINE_COMM_MODE_1, channel); /* Configure the McSPI bus clock depending on clock mode. */ McSPIClkConfig(baseAdd, MCSPI_IN_CLK, MCSPI_OUT_FREQ, channel, MCSPI_CLK_MODE_1); /* Configure the word length.*/ McSPIWordLengthSet(baseAdd, MCSPI_WORD_LENGTH(8), channel); /* Enable the transmitter FIFO of McSPI peripheral.*/ McSPITxFIFOConfig(baseAdd, MCSPI_TX_FIFO_ENABLE, channel); /* Enable the receiver FIFO of McSPI peripheral.*/ McSPIRxFIFOConfig(baseAdd, MCSPI_RX_FIFO_ENABLE, channel);
The functions behind these calls are the same as the example projects. There must be something we're missing here, thanks for the help!
Although I'm replying a year late, I reckon my answer might help someone in the future. The only significant change in my code that worked was that I replaced MCSPI_SINGLE_CH with MCSPI_MULTI_CH in the following line of code:-
/* Perform the necessary configuration for master mode.*/ McSPIMasterModeConfig(baseAdd, MCSPI_SINGLE_CH, MCSPI_TX_RX_MODE, MCSPI_DATA_LINE_COMM_MODE_1, channel);
I have the same situation presented by Lars in the OP.
Using tips and answers found elsewhere in the forums, I have patched STARTERWARE to allow for SPI communications on a BeagelBone Black. I am using both SPI0 and SPI1 (CS0 on each) to talk to two devices (an ADC and a DAC).
My SPI code is derived from the McSPI Flash example. One of the issues I am having with this setup is that I am required to control the CS (SPIEN) generation MANUALLY using McSPICSAssert() and McSPICSDeAssert to get any communications at all. My read of the TRM suggests that unless I NEED the SPIEN to be active between bytes (as in the McSPI Flash example) then the SPIEN generation should be automatic. My SPI configuration code has the same look and feel of the code listed above by Lars.
Any assistance in resolving this issue would be greatly appreciated.
Check the status of bit1 in the following register (you'll probably need to use the watch window):
its on pg. 4044 of my TRM.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.