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.

TDA4VM: Use OSPI controller as default SPI controller

Part Number: TDA4VM

Tool/software:

Hi TI,

due to lack of SPI instances, we need to use OSPI Controller (MCU_OSPI1) for standard SPI communication. I configured the controller the following way:

uint32_t spiInstance = 1;  // MCU_OSPI1
uint32_t spiChannel = 1;
OSPI_Params spiParams;
OSPI_v0_HwAttrs spiConfig;
OSPI_Params_init(&spiParams);
spiParams.transferMode = OSPI_MODE_BLOCKING;
spiParams.bitRate = 10000000;            // SPI Frequency in Hz
spiParams.frameFormat = OSPI_POL0_PHA0;  // SPI Mode 0
spiParams.mode = OSPI_MASTER;
spiParams.dataSize = 8;  // 8 Bit Interface
spiParams.transferCallbackFxn = nullptr;

OSPI_socGetInitCfg(SPI_OSPI_DOMAIN_MCU, spiInstance, &spiConfig);
spiConfig.chipSelect = spiChannel;
spiConfig.intrEnable = false;
spiConfig.operMode = OSPI_OPER_MODE_CFG;
spiConfig.phyOpMode = CSL_OSPI_CFG_PHY_OP_MODE_DEFAULT;
spiConfig.dacEnable = false;
spiConfig.phyEnable = false;
spiConfig.dtrEnable = false;
spiConfig.xferLines = OSPI_XFER_LINES_SINGLE;
spiConfig.frmFmt = CSL_OSPI_CLK_MODE_0;

configClk(OSPI_MODULE_CLK_166M, true, domain, instance); // Taken from OSPI Flash test code

OSPI_socSetInitCfg(spiDomain, spiInstance, &spiConfig);

OSPI_init();

OSPI_Handle spiHandle = OSPI_open(spiDomain, spiInstance, &spiParams);

As a test, I transfer the following data:

OSPI_Transaction transactionData;
bool isSuccessfull;

uint8_t transmitBuffer[3];
transmitBuffer[0]=0x11;
transmitBuffer[1]=0x33;
transmitBuffer[2]=0x55;

transactionData.count = 3;
transactionData.txBuf = &transmitBuffer;
transactionData.rxBuf = nullptr;

isSuccessfull = OSPI_transfer(spiHandle, &transactionData);

I get the following signals (Green: SCLK, Blue: MOSI):

There are following problems with the resulting signals:

  1. CLK frequency is 5.2 MHz instead of 10 MHz (configured via spiParams)
  2. A Data Frame is not limited to 8 Bit
  3. There is one additional 8 Bit data frame appended (32 bit instead of 24)
  4. Only the first 8 bit are transmitted correctly

The TRM mentions, that SPI Legacy mode

"allows the user to issue any FLASH instruction to the device, but does place a heavy software
overhead in order to manage the fill levels of the FIFO’s effectively."

But there is little explanation on how to implement SPI Legacy mode, except of setting bit 8 (ENB_LEGACY_IP_MODE_FLD) in OSPI_CONFIG_REG register.
My questions are:

If I want to achieve standard SPI behaviour, do I have to use legacy mode? Can I fix the above mentioned problems (1. - 4.) also in non legacy mode?

If I have to use legacy mode, is there a more detailed description on what to do?

Thanks for your help and best regards,

Felix

  • Hi TI,

    I was able to solve problem 3. and 4. with the following changes:

    OSPI_Transaction transactionData;
    bool isSuccessfull;
    
    uint8_t transmitBuffer[3];
    transmitBuffer[0]=0x11;
    transmitBuffer[1]=0x33;
    transmitBuffer[2]=0x55;
    
    transactionData.count = 3;
    transactionData.txBuf = &transmitBuffer;
    transactionData.rxBuf = nullptr;
    uint32_t dataLen=0;
    transactionData.arg = (void *)(uintptr_t)dataLen;
    
    uint32_t         transferType = SPI_TRANSACTION_TYPE_WRITE;
    
    /* Update the mode and transfer type with the required values */
    OSPI_control(spiHandle, OSPI_V0_CMD_SET_CFG_MODE, NULL);
    OSPI_control(spiHandle, OSPI_V0_CMD_XFER_MODE_RW, (void *)&transferType);
    
    isSuccessfull = OSPI_transfer(spiHandle, &transactionData);

    However, it seems, that this is not a full duplex communication, since on MISO signal I get some kind of bus contention (signal stays at approx. half of the max value).

    Best regards,

    Felix

  • Just one follow up question:

    I aam trying to send a read transaction the following way:

    OSPI_Transaction transactionData;
    bool isSuccessfull;
    uint8_t transmitBuffer[7] = {};
    uint8_t receiveBuffer[7] = {};
    
    uint32_t transferType = SPI_TRANSACTION_TYPE_READ;
    /* Update the mode and transfer type with the required values */
    OSPI_control(spiHandle, OSPI_V0_CMD_SET_CFG_MODE, nullptr);
    OSPI_control(spiHandle, OSPI_V0_CMD_XFER_MODE_RW, (void *)&transferType);
    
    transmitBuffer[0] = 0x02;
    
    transactionData.count = 7;
    transactionData.txBuf = transmitBuffer;
    transactionData.rxBuf = receiveBuffer;
    uint32_t dataLen=0;
    transactionData.arg = (void *)(uintptr_t)dataLen;
    
    isSuccessfull = OSPI_transfer(spiHandle, &transactionData);

    I get the following signals for MISO (Blue) and SCLK (Green):

    The first 8 bit (as said in the previous post) are a bit strange. After that, the signal looks as expected. However, the first 8 bit contain the information I want to read and OSPI driver API does not return this information.

    Is there a way to get access to the first 8 bit via OSPI driver?

    Best regards,

    Felix

  • Hi Felix,

    The TRM mentions, that SPI Legacy mode

    "allows the user to issue any FLASH instruction to the device, but does place a heavy software
    overhead in order to manage the fill levels of the FIFO’s effectively."

    But there is little explanation on how to implement SPI Legacy mode, except of setting bit 8 (ENB_LEGACY_IP_MODE_FLD) in OSPI_CONFIG_REG register.
    My questions are:

    If I want to achieve standard SPI behaviour, do I have to use legacy mode? Can I fix the above mentioned problems (1. - 4.) also in non legacy mode?

    If I have to use legacy mode, is there a more detailed description on what to do?

    Please take a look at this ticket for OSPI legacy mode info. Unfortunately, as stated before, this is not something we support from H/W standpoint. It also seems there is a lot of software overhead needed for legacy mode as well, which our I believe software does not have support for.

    due to lack of SPI instances, we need to use OSPI Controller (MCU_OSPI1) for standard SPI communication.

    Are you sure there are no other SPI instances you can use other than trying OSPI controller? Can you explain what all the other SPI instances are currently used for ?

    Best Regards,

    Matt

  • Hi Matt,

    thanks for your quick reply.

    Please take a look at this ticket for OSPI legacy mode info

    Which ticket are you referring to here?

    Unfortunately, as stated before, this is not something we support from H/W standpoint

    Can you please elaborate a little more on this statement? Which functions are not supported from HW standpoint on OSPI controller?

    Can you explain what all the other SPI instances are currently used for ?

    The SPI instance needed must have 3V3. The only remaining SPI instance is in 1V8 domain. To save components, we decided to use MCU_OSPI1 controller instead, which is in 3V3 domain.

    Referring to my last post:

    I think the only "real" remaining problem is, that the first byte of the MISO signal is not evaluated by the driver (see attached screenshot in my last post from Sep 3; blue signal is MISO). Is there any possibility to get access to this byte using the OSPI driver as it is?

    Thanks again and best regards,

    Felix

  • Hi Felix,

    Which ticket are you referring to here?

    Unfortunately, as stated before, this is not something we support from H/W standpoint

    Can you please elaborate a little more on this statement? Which functions are not supported from HW standpoint on OSPI controller?

    Apologies, this is the ticket I was referring to: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/946418/faq-tda4vm-is-there-a-guide-to-choosing-the-right-ospi-flash-parts-that-are-supported-on-jacinto-7

    Software doesn't really support Legacy Mode because of the software overhead, so it is not validated from a H/W standpoint.

    I think the only "real" remaining problem is, that the first byte of the MISO signal is not evaluated by the driver (see attached screenshot in my last post from Sep 3; blue signal is MISO). Is there any possibility to get access to this byte using the OSPI driver as it is?

    Let me discuss with some other experts and loop in software to see if this is possible.

    Best Regards,

    Matt