PROCESSOR-SDK-AM437X: Potential improvement for "QSPI_BasicExample_idkAM437x_armExampleProject "

inno

Hello,

I am running the QSPI_BasicExample_idkAM437x_armExampleProject on a Sitara AM437x IDK. I am using SDK version 6.3.0.106.

There is something in the example main file that looks like it could be improved. I am referring to the following file:

C:\ti\pdk_am437x_1_0_17\packages\ti\drv\spi\example\qspi_flash\src\main_qspi_flash_read_write.c

Before I start with the potential improvement I would like to first state that there is 2-times an information available about the driver mode inside the QSPI_v1.c driver. I searched for “hwAttrs->operMode” inside the QSPI_v1.c driver and I found only one occurrence, which I highlighted below in the red rectangle:

As you can see, the information is being copied into “object->qspiMode” when open the SPI handle. This leads me to the assumption that “hwAttrs->operMode” is some kind of default value but “object->qspiMode” is finally the applied mode inside the QSPI driver (“object->qspiMode” is used e.g. inside the “QSPI_read_v1” and “QSPI_write_v1” function).

Furthermore, the code of the NOR flash driver either looks at “object->qspiMode” or modifies that object temporarily via an “SPI_control(handle, SPI_V1_CMD_SETCONFIGMODE, NULL);” instruction.

Let me now come to the potential improvement. I identified the following code inside the example function “spi_read_write”:

As you can see above, the variable “addressValue” becomes either a pointer to a variable, which holds the flash address to be accessed, or the flash address itself. And this is done based on the “hwAttrs->operMode”.

But the functions inside the NOR flash driver do not look at “hwAttrs->operMode” but rather at “object->qspiMode” (and theoretically a user may have changed that driver setting during the run-time of the code). See here:

So that example project only works in case that any NOR flash driver function restores the default driver mode as e.g. at the end of the function “S25FLFlash_BlockErase”, which is of course the case:

That means that the example itself is correct but I believe that it would be a better idea to let the “spi_read_write” function set the variable “addressValue” based on “object->qspiMode” instead of “hwAttrs->operMode”, since only “object->qspiMode” is the one that is being used inside the NOR flash driver (F25FL.c) and the QSPI driver itself (QSPI_v1.c).

Does it make sense?

over 3 years ago

0 Dillon Frank over 3 years ago

TI__Intellectual 2615 points

Hi Inno,

For the first part of your response, the value of operMode is defined by whichever mode is specified by the handle that's passed into QSPI_open_v1(), and can be one of the following values:

    SPI_OPER_MODE_BLOCKING = 0U,  /*! Interrupt based blocking mode */
    SPI_OPER_MODE_POLLING,        /*! Non interrupt based blocking mode */
    SPI_OPER_MODE_CALLBACK        /*! Interrupt based call back mode */

And for the second part of your response, thank you for pointing out this detail. You're right that there's an edge case where the values of "hwAttrs->operMode" and "object->qspiMode" could differ during run-time. I'll go ahead and share this with the development team to see about fixing this.

Regards,

Dillon

Processors

Processors forum

PROCESSOR-SDK-AM437X: Potential improvement for "QSPI_BasicExample_idkAM437x_armExampleProject "