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?
Frederic
Hi Fredric
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);"
Regards
Jeethan
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.
Hi Frederic
To the original application file(mcspiFlash_edma.c) these are the modifications i did -
1) Commented McSPI0CSPinMuxSetup(MCSPI_CH_NUM);
2) McSPICSEnable(SOC_SPI_0_REGS);
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.
Hi,
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.