TI E2E Community
SPI Flash with external Chip Select
Hi,I'm testing the mcSPIFlash_edma example that is provided in the Starterware 02_00_00_05 and this example works well so far on the EVM board evaluation module.For my typical testing I need to use an external Chip select (I cannot use functions provided by SPI API to drive the chip select)To be able to use SPI in 3 pins I tried to modify the example mcSPIFlash_edma.
Unfortunately, it's not working. No communication is done by EDMA so I’m not catching any interrupt from it to set the flagTx and flagRx. So I get stuck in the while((0 == flagTx) || (flagRx == 0)).Is there a typical configuration to set the SPI module to use it in 3 pins mode?
1) Have you done a probe on CS pin(SPI0_CS0) when you drive logic low/high using GPIOPinWrite()? If you dont see the desired level then pinmuxing should be the issue.
2) I assume you have replaced McSPICSAssert(SOC_SPI_0_REGS, MCSPI_CH_NUM) API with GPIOPinWrite(SOC_GPIO_0_REGS, pinNumber, pinValue) and McSPICSDeAssert(SOC_SPI_0_REGS, MCSPI_CH_NUM) with GPIOPinWrite(SOC_GPIO_0_REGS, pinNumber, pinValue) where pinNumber = 5 and pinValue = 0,1 respectively.
3) Commenting McSPICSEnable(SOC_SPI_0_REGS) will not disable CS of McSPI Controller. To enable/disable CS we have to program PIN34 of MCSPI_MODULCTRL register.
To enable CS -> PIN34 = 0
To disable CS-> PIN34 = 1
PIN34 = 0 after reset. Hence on commenting McSPICSEnable(SOC_SPI_0_REGS) will not disable CS cause PIN34 will still be 0. To disable CS we have to use McSPICSDisable(SOC_SPI_0_REGS) API. However i feel this should not be the issue since we are not performing pinmux for CS of McSPI Controller.
According to McSPI Technical reference manual to configure McSPI in Single-Channel Master Mode(with 3 pin only) the field PIN34 of MCSPI_MODULCTRL register and field SINGLE of MCSPI_MODULCTRL register should be set to 1. Setting of field SINGLE is done within the API
"McSPIMasterModeConfig(SOC_SPI_0_REGS, MCSPI_SINGLE_CH, MCSPI_TX_RX_MODE, MCSPI_DATA_LINE_COMM_MODE_1, MCSPI_CH_NUM);"
Note: If this post answers your question, please click the Verify Answer button below. Thank you!
Thanks for the prompt answer.
1) Yes I done a probe on CS pin (SPI0_CS0) and I can see that my pin seems to be drive as I want.
2) Yes that's exactly what I did.
3) I forgot to specified it but I'm already using the McSPICSDisable(SOC_SPI_0_REGS). The McSPIMasterModeConfig(SOC_SPI_0_REGS, MCSPI_SINGLE_CH, MCSPI_TX_RX_MODE, MCSPI_DATA_LINE_COMM_MODE_1, MCSPI_CH_NUM) is set exactly the same way.
I did another test, I comment everything from the API concerning the chip select. I comment all the modification I did concerning the GPIO.
If I run the test like this it's not working and that's normal, but if I uncomment the McSPICSAssert() and McSPICSDeAssert() and only those two functions it's working!
On the probe on CS pin(SPI0_CS0) I can see that the pin it's not drive and stay at 0. But the communication with the SPI memory is working. It seems that I need to use the McSPICSAssert() and McSPICSDeAssert() to be able to lunch the communication with the SPI memory.
To the original application file(mcspiFlash_edma.c) these are the modifications i did -
1) Commented McSPI0CSPinMuxSetup(MCSPI_CH_NUM);
3) McSPICSPolarityConfig(SOC_SPI_0_REGS, MCSPI_CS_POL_LOW, MCSPI_CH_NUM);
These are the observations upon execution -
1) On probing CS(SPI0_CS0) i can see value "high" when FORCE bit of MCSPI_CHCONF is set/reset(i.e. upon calling of McSPICSAssert & McSPICSDeAssert respectively)
2) Application did not work for me. Communication with SPI_FLASH is not happening. How i came to know is on reading the status register of SPI_FLASH. I am not getting the desired value which i was getting before commenting the above mentioned APIs. Value which i get is 0xFF.
As explained before for my typical testing I need to use an external Chip select. That's the reason why I don't want to use the different API from the starterware regarding Chip Select.
After many testing configurations I found the solution, here is what I did:
That was my first configuration which was not working properly due to DMA issues apparently.
To be able to resolve that issue I had to use the McSPICSAssert(SOC_SPI_0_REGS, MCSPI_CH_NUM) function in the init part of the test, without it no communication appears on DMA.
The problem is now resolved but I don't really get why we have to use this function and how this function can work when McSPICSDisable(SOC_SPI_0_REGS) function is called earlier.
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.