AM437x QSPI EDMA Support

Checking on this with additional chip experts. Looking at the documentation on QSPI and EDMA, I do not see a QSPI event hooked up to EDMA.

Will confirm

Regards

Mukul

Dave, Mukul,

Feedback from customer below:

"The QSPI Controller doesn’t work correctly and both versions of the TRM,  SPRUHL7 May 2013 and  January 2014, had it documented incorrectly.

The result of this bug plus a lack of QSPI Event connected to EDMA means that this QSPI controller is less efficient than using a McSPI with EDMA.

On  TRM January 2014, Page 3831,  it stated that the QSPI can do 128 bit word  read by setting the WLEN field in the QSPI_CMD_REG to 127 and using the four QSPI_DATA_REG[3:0].  Problem with this is that the WLEN field is only 5 bits wide and can only be set to 31 for only a 32 bit read.  I am guessing that the MS 2 bits of the WLEN field was accidently removed since that MS byte of the QSPI_CMD_REG also contained the CSNUM field which became obsolete due to this QSPI controller only supporting 1 CS instead of 4.

The result of this bug means that the CPU will have to handle four times as many interrupts.  A 32 bit QUAD mode read will take 0.157uSecs( 8 clocks/48000000)  to complete while a 128 bit read will take 0.667uSecs(32 clocks/48000000).   I will be hit with a high rate of interrupts when reading from the flash.

This bug with the lack of the EDMA means that this QSPI controller may end up being less efficient than using a McSPI with EDMA.   If there are plans to rev this chip, please have them fix the WLEN at a minimum and if possible, add a QSPI event to the EDMA so that the full potential of this controller can be utilized."

ideas?

Shashwat Tyagi said:

Dave, Mukul,

Feedback from customer below:

"The QSPI Controller doesn’t work correctly and both versions of the TRM,  SPRUHL7 May 2013 and  January 2014, had it documented incorrectly.

Keep in mind that the documents you are referring to were very early drafts and were watermarked as such. The June 2014 draft TRM was correct, as is the currently available TRM on TI.COM.

Shashwat Tyagi said:

The result of this bug plus a lack of QSPI Event connected to EDMA means that this QSPI controller is less efficient than using a McSPI with EDMA.

 

On  TRM January 2014, Page 3831,  it stated that the QSPI can do 128 bit word  read by setting the WLEN field in the QSPI_CMD_REG to 127 and using the four QSPI_DATA_REG[3:0].  Problem with this is that the WLEN field is only 5 bits wide and can only be set to 31 for only a 32 bit read.  I am guessing that the MS 2 bits of the WLEN field was accidently removed since that MS byte of the QSPI_CMD_REG also contained the CSNUM field which became obsolete due to this QSPI controller only supporting 1 CS instead of 4.

In the case of QSPI, although the IP used is capable of bursting data lengths of up to 128 bits, the design decision was made to restrict this to 32 bits (for AM43xx) based on the use-cases presented during the device definition phase. As the silicon functionality matches the device specification, this isn't a bug. 

Shashwat Tyagi said:

 

...If there are plans to rev this chip, please have them fix the WLEN at a minimum and if possible, add a QSPI event to the EDMA so that the full potential of this controller can be utilized."

ideas?

There are no current plans to rev this chip, but your feedback regarding both QSPI burst-size and EDMA event connections have been captured for consideration on future devices. Thank you for that.

Hello,

Due to the shortcoming of the QSPI interface,  I am trying to use the EDMA to do a block move between the QSPI MMP and DDR.  I was able to get the block move to work since I used code that works on a OMAP-L138 EDMA to a memory mapped NOR flash.   However, on this AM4376 EDMA to QSPI MMP, writing to the flash works some of the time. Reading seems to work but appears to corrupt memory on the stack.

My EDMA configuration consists of one PRAM and does a byte transfer.

  pram_ptr->DST_SRC_BIDX = (U32)0x00010001;  // U8 src and dest
  pram_ptr->LINK_BCNTRLD = (U32)0x0000FFFF;
  pram_ptr->DST_SRC_CIDX = (U32)0x00000000;
  pram_ptr->CCNT = (U32)0x00000001;
  pram_ptr->SRC = (U32)source;
  pram_ptr->B_A_CNT = (N << 16) | 0x00000001;
  pram_ptr->DST = (U32)destination;

Any reason why I am getting inconsistent behavior?

Thanks,

Victor