QN9090DK6 spifi_polling_transfer Failed

[Prashanth_Baradhi]

Hello,

       I am working on the Serial External Flash of QN9090 using the SPIFI interface. QN9090DK6,  SDK version 2.6.5. I am using the SDK example 'spifi_polling_transfer' as reference.

      The program isn't executing as expected . Please advice on how to resolve this issue. I have attached screenshot of the output obtained in PUTTY. Is there a way to reset the QN9090 board as a way of erasing any previous codes that might be interfering with the execution? or is there something else I am doing wrong?

Regards,

Prashanth

[Gavin_Jia]

Hi @Prashanth_Baradhi ,

Thanks for contacting NXP support.

Judging from this error message, it is an error caused by inconsistent read verification.

Specifically, there are mainly the following processes:

1. Erase sectors: SPIFI_SetCommand(EXAMPLE_SPIFI, &command[SE]);
2. Write a page of data to the sector: SPIFI_SetCommand(EXAMPLE_SPIFI, &command[PP]);
3. Read sector data for verification: SPIFI_SetMemoryCommand(EXAMPLE_SPIFI, &command[READ]);
4. Compare read data with original data: if (*val != g_buffer[i % PAGE_SIZE])
5. Print error when inconsistent: PRINTF("Data error...");

So the reason for this print statement is that after the Flash programming data, the read verification fails, and the wrong address and value are printed.

It is necessary to check that there is no problem with the writing process, or there may be a problem with the Flash chip itself, resulting in the inability to store the written data correctly.

Best regards,

Gavin

[Prashanth_Baradhi]

Hi @Gavin_Jia,

Thank you for your response, I have understood the flow of the processes you mentioned I guess I should've also mentioned that it worked perfectly before wherein there were no issues in writing and reading during data verification., I even printed the values to see what was happening.

It wasn't until I changed the value in the 'g_buffer' from where data is being taken to write into the flash that I encountered this error FIRST. Only when I revisited the original code later did I realise that this problem persisted.

You mentioned 

"It is necessary to check that there is no problem with the writing process, or there may be a problem with the Flash chip itself, resulting in the inability to store the written data correctly."

Could you please elaborate on how to go about checking to see if the writing process has a problem 

and also how to determine if the Flash Chip is itself the issue and steps I need to take to resolve it.

Grateful for your response.

Regards,

Prashanth

[Gavin_Jia]

Hi @Prashanth_Baradhi ,

Thanks for the additional info, it's very useful.

Because it worked normally before, the problem of hardware connection and chip failure is basically ruled out. So, we focus on the software side.

Please pay attention to the code snippet   "/* Program page */":

Through two for loops, it take out 4 bytes of data from g_buffer[]:

1. The outer for loop takes 4 bytes each time
2. The inner for loop combines each byte bitwise into a 32-bit data

Then call SPIFI_WriteData to write combined 32-bit data. Loop until all pages of the sector are written.

When verifying, read the g_buffer[] data and compare it with the flash data. The data in the g_buffer[] has always been the test data with the count incremented. This is the whole logic of these codes. If you modify the g_buffer[] and cause previous errors, it should be that the code is not well understood. Please debug in this direction.

Wish it helps！

Best regards,

Gavin

[Prashanth_Baradhi]

Hi @Gavin_Jia,

Thank you again for your response, I have created two separate projects and just to be safe have also tried two different workspace. One project/workspace has the untouched SDK Example of 'spifi_polling_transfer', while the other has my modified code.

Now I understand that my modified code might be giving problems, but when I try to run the stock example which is clear from any modifications, I am facing the same Data Error issue. My goal is if I can at least get the SDK example working, then I can check for errors in my modified code.

So is there a "Factory Reset" option per se or something similar that I can perform on the board so that I may be able to at least rerun the working example.

I would like to post the example code here just so you know what I am working with, but I fear I may be disclosing any NDA files that I have signed with NXP.

Thanks again,

Regards,

Prashanth