RTOS/AM5718: QSPI CSL maximum word length

Nathan Rabenold

Part Number: AM5718

Tool/software: TI-RTOS

Hi-

I am using the QSPI CSL and am attempting to use a word length of 128 bits (the maximum allowed). This requires that I set QSPI_SPI_CMD_REG bits 25:19 to "1111111". If you look at the CSL function for setting the command register, however, this can never be done:

void QSPISetCfgModeTxCmd(uint32_t baseAddr, HAL_QSPI_Command_t qspitxcmd)
{
    uint32_t regVal;

   ...

    HW_SET_FIELD32(regVal, QSPI_SPI_CMD_REG_WLEN,
        qspitxcmd.wordLength - 1U);

    ...

    /* Set the value of QSPI command in the command register */
    QSPIsetCommandReg(baseAddr, regVal);
}

The problem is that the bitfield HAL_QSPI_Command_t.wordlength is only 7 bits. Even if I pass in "1111111" in this argument, it will be decremented by 1 before being written to the command register. Therefore, the maximum the CSL allows us to configure is a word length of 127 bits. After much time spent finding this problem, I plan to just include writing to the register directly from my application.

Is there any way this can be fixed in an upcoming release?

Thanks,

Nate

over 9 years ago

0 Biser Gatchev-XID over 9 years ago

TI__Guru**** 393215 points

The RTOS team have been notified. They will respond here.

0 Rahul Prabhu over 9 years ago

TI__Guru** 116950 points

Nate,

Just a clarification, the wordlength parameter is defined as uint32 so I am guessing you can pass "10000000" to that field and get to the 128 bit configuration with the current API.

I think the API was written from the LLD driver perspective, where we expect the users to provide the actual word length that needs to be configured rather than the register setting. Please check the way the word length gets used from the QSPI_v1.c driver along with the example main_qspi_flash_test.c test.

There is a MCSPI and QSPI driver update coming in the upcoming release in 1Q17 but I don`t think there is any major CSL update planned unless it identified as critical. Please let us know if this blocks your development in any way.

Regards,
Rahul

0 Nathan Rabenold over 9 years ago in reply to Rahul Prabhu

Intellectual 755 points

Rahul,

The wordlength field is a 7-bit field of the HAL_QSPI_Command_t bitfield type. How can you pass "10000000" to that field? Regardless of how the API is used by the LLD, with the given function arguments, I don't see any way that you could ever have the word length register bits configured to "1111111" (because of the 7-bit size of this field). Even if somehow, the compiler is able to properly handle an excessive size value written into the bitfield, is this really the way it's intended to be used?

Nate

0 Nathan Rabenold over 9 years ago in reply to Nathan Rabenold

Intellectual 755 points

Put another way, pretend I had my QSPI low-level driver parameters configured for a 128-bit data size. The same problem is going to exist when the low-level driver calls QSPISetCfgModeTxCmd(). It is trying to assign a decimal value of 128 to a 7-bit field in the cmd structure:

static void QSPI_cmd_mode_read_v1(SPI_Handle handle,
const SPI_Transaction *transaction)
{
...
cmd.wordLength = object->qspiParams.dataSize; <--- This is not valid when "dataSize" is equal to 128 bits.
...
/* Write tx command to command register */
QSPISetCfgModeTxCmd(hwAttrs->baseAddr, cmd);
...
}

0 Rahul Prabhu over 9 years ago in reply to Nathan Rabenold

TI__Guru** 116950 points

Hi Nate,

Yes, I gave this a try with my setup and observed the issue that you are reporting. The correct way to handle this would be to remove the -1 from the CSL code and ask the User to pass (Word Length value -1) as the configuration from that field.

I will bring this up with the developer and let you know if he has any comments regarding this issue.

Regards,
Rhul

0 Rahul Prabhu over 9 years ago in reply to Rahul Prabhu

TI__Guru** 116950 points

Nathan,

I am just circling back on this issue to confirm that this issue was resolved at your end. We want to make an update for this in the SDK and need to know if that fix worked for you. I am providing a screenshot of the fix we plan to provide to resolve this issue:

We don`t have an appropriate hardware that requires word length of 128 so it would be nice if you can confirm the fix. We appreciate if you can help us verify this corner case.

Regards,

Raahul

0 Nathan Rabenold over 9 years ago in reply to Rahul Prabhu

Intellectual 755 points

I can't say if I agree with the code or not. If you remove the decrementing by 1 in the CSL, are you updating the low-level driver to now pass "wordLength -1" in th qspitxcmd structure?

I actually prefer the original method of having everything above the CSL store the true "wordLength" in number of bits and to take care of the decrementing when we actually write to QSPI_SPI_CMD_REG. All we needed was a structure above the CSL capable of storing the maximum value of 128. Here is how I implemented a workaround in our application code. Our application bypasses the horrendously slow low-level driver and directly accesses the CSL to allow us to set the frame and word length on-the-fly based on the requested read/write operation. This made it easy for us to just declare our own 32-bit variable "wordLength" and not use the 7-bit field in the HAL_QSPI_Command_t structure.

// We cannot call QSPISetCfgModeTxCmd to write the tx command. There is a bug in this CSL function that prevents us from being
// able to set the word length to the 128 bit maximum (due to the bitfield length of the argument and function implementation.
// Read value of the qspi command register
regVal = QSPIgetCommandReg(hwAttrs->baseAddr);

// Set value of all the fields for qspi command
HW_SET_FIELD32(regVal, QSPI_SPI_CMD_REG_CMD, cmd.trCmd);
HW_SET_FIELD32(regVal, QSPI_SPI_CMD_REG_FIRQ,
		               cmd.firq);
HW_SET_FIELD32(regVal, QSPI_SPI_CMD_REG_WIRQ,
		               cmd.wirq);
HW_SET_FIELD32(regVal, QSPI_SPI_CMD_REG_WLEN,
		               wordLength - 1U);
HW_SET_FIELD32(regVal, QSPI_SPI_CMD_REG_FLEN,
		               cmd.frameLength - 1U);  //lint !e835
HW_SET_FIELD32(regVal, QSPI_SPI_CMD_REG_CSNUM, cmd.cs);

// Set the value of QSPI command in the command register
QSPIsetCommandReg(hwAttrs->baseAddr, regVal);

0 Nathan Rabenold over 9 years ago in reply to Nathan Rabenold

Intellectual 755 points

In thinking about this more, this may not even be a bug.

If I think about a setting of 128 bits, the low-level driver would try to set cmd.wordLength equal to 128. Since cmd.wordLength is only 7 bits, I assume it would actually get the value 0. We then pass this into the QSPISetCfgModeTxCmd() function, which decrements it by 1 before setting the register value. Decrementing by 1 would presumably roll us back around to 127, which is the desired setting for 128bits.

While not the most intuitive implementation, I believe this is working since I did not implement a similar workaround for frameLength, but we are also using the maximum value of 4096 for that field without any problems.

Processors

Processors forum

RTOS/AM5718: QSPI CSL maximum word length