This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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.

  •  I comment the functions: McSPI0CSPinMuxSetup(MCSPI_CH_NUM), McSPICSEnable(SOC_SPI_0_REGS), McSPICSPolarityConfig(SOC_SPI_0_REGS, MCSPI_CS_POL_LOW, MCSPI_CH_NUM), McSPICSAssert(SOC_SPI_0_REGS, MCSPI_CH_NUM) and McSPICSDeAssert(SOC_SPI_0_REGS, MCSPI_CH_NUM).
  • I declare the CS pin (SPI0_CS0) in GPIO mode to drive it out of the functions of SPI API.
  • Before a read or write SPI action a put the SPI0_CS0 pin at the low level using GPIOPinWrite() and put it back in the high level at the end of the read or write.


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.

    Regards

    Frederic

     

  • 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.

    Regards

    Jeethan

  • 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:

    •  I comment the functions: McSPI0CSPinMuxSetup(MCSPI_CH_NUM), McSPICSEnable(SOC_SPI_0_REGS), McSPICSPolarityConfig(SOC_SPI_0_REGS, MCSPI_CS_POL_LOW, MCSPI_CH_NUM).
    • I put McSPICSDisable(SOC_SPI_0_REGS) instead of McSPICSEnable(SOC_SPI_0_REGS).
    • I declare the CS pin (SPI0_CS0) in GPIO mode to drive it out of the functions of SPI API.
    • Before a read or write SPI action a put the SPI0_CS0 pin at the low level using GPIOPinWrite() and put it back in the high level at the end of the read or write.

    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.

    Frederic