The data read by QSPI does not match the actual data

[luffy1]

I am having headache with controlling a Macronix MX25UW51245G QSPI seial NOR flash from an S32G399A.

I configured with the EB Tresos tool. 

Fls driver configuzration, 
- otcal DDR mode 100mhz

NXP Realtime-Driver Package SW32G_RTD_4.4_4.0.0

Problem: During the process of continuously reading and writing flash (4k bytes each time), there is a very low probability that I will encounter inconsistencies between the read and written data (such as writing data of 0x10 and reading data of 0xff). I am not sure if this instability is caused by my incorrect fls configuration. Can you provide me with a fls configuration file for the ddr mode of 100Mhz for my reference, Or have some other suggestions, thank you

[Daniel-Aguirre]

Hi,

We understand that a Fls example is provided for EB Tresos, are you using this example? It is provided as DDR-200MHz, for what it is described under the "readme.txt":

"The application shows the user how to initialize the QuadSPI module and the MX25UW51245G 64MB octal flash memory chip to work in DTR-OPI mode at 200 MHz."

Is this a custom board? Or are you using an NXP development board?

Please, let us know.

[luffy1]

Is a custom board， not NXP development board.

Due to the feedback from our team's hardware department that the 100mhz DDR signal is the best, I referred to the example of fls 200mhz in EB to configure the 100mhz DDR mode, but I am not sure which configuration items need to be adjusted

[Daniel-Aguirre]

Hi,

We understand that by changing the frequency of the module to the operating frequency should put your QSPI speed @ 100MHz.

Still, there might need to be additional configurations required since the frequency has been modified. The following is told from our internal team:

"Configuring the QSPI controller work in higher frequency, would not only require changing the clock Muxes in the RTD Mcu driver, but also configuring the QSPI controller in the Fls driver to add the support for this. 

However, this depends on the external flash memory datasheet requirements, as well as the QSPI controller datasheet requirements"

Please, let us know.

[luffy1]

Hi, the external flash I use is MX25UW51245G, but I cannot upload the data sheet of this chip here. Is there any other way for me to provide the data sheet to you?

The picture below is the QSPI controller configuration I saw in the s32g3 data sheet. What else do you need me to provide? Please let me know, thank you.

[Daniel-Aguirre]

Hi,

We may be misunderstanding your overall request, we do apologize.

As you are seeing under the S32G3 datasheet, we provide some values for the configuration. Did you use these values on your configuration? If so, which column?

Have you verified the signals on your board?

Please, let us now.

[luffy1]

Hi, I am using the values for DDR-133Mhz for configuration, because according to the description in the datasheet these values are for both 100 and 133mhz.

Sorry, I don't know how to verify the signal, but in most cases the results of erasing/writing/reading flash are correct. It may take thousands or more reads and writes before a problem occurs, so I I want to confirm whether my fls configuration is correct and stable first. It would be great if you could provide me with the 100mhz fls configuration of (MX25UW51245G-automotive) for reference.

Below is the data sheet of MX25UW51245G-automotive and my own fls configuration file. I hope it can help you find my problem early. Thank you very much.

[Daniel-Aguirre]

Hi,

Thanks for your feedback. Since this behavior you are seeing is not consistent (as of seeing this since the beginning of the communication), could be a problem that ranges from the physical lanes all the way to even tolerances of the overall interface. A signal integrity analysis might be required to confirm that the physical interface is able to handle the frequencies being used.

Since this is a custom board, we might not be able to reproduce the behavior you are seeing. We recommend contacting your local NXP FAE, for them to provide a better support on these scenarios. We do apologize.

Please, let us know.