QSPI0 Flash Mis-read

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

QSPI0 Flash Mis-read

Jump to solution
1,344 Views
peterwoolley
Contributor III


We have a situation where our M4 XIP build starts-up fine but at some point the QSPI0 attached flash starts to be mis-read.

The symptom looks like 1-bit per byte has been reset (const text has 'S' become 'Q' for example).

WIth the SAME functionality this situation goes away if some functions are moved to separate .c files, or if functions are removed from some .c files.

There appears to be no relation between the functions being moved and the symptom ... often the code is not called unless invoked from a terminal shell program.

The situation is corrected by reset, but occurs again as the code begins to run.

Does anyone have any idea what could cause this symptom?

1 Solution
1,035 Views
CommunityBot
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

View solution in original post

0 Kudos
14 Replies
1,036 Views
CommunityBot
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!
0 Kudos
1,036 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi,

I am watiting for Peter's answer.I wonder if you are still having problems or if you found something useful.

Best Regards,

Alejandro

0 Kudos
1,036 Views
peterwoolley
Contributor III

Not sure what question I haven't answered.  The situation that I have is very strange.  We have an MQX radio application running XIP on the M4 core of an M4 boot first Vybrid part.

We have two relevant 'power modes'; standy and full-run.

Our application comes up in standby mode, and all is well.  The code is running as expected, and the IAR debugger is showing data/code as expected.  I can open a memory view window, and set it to periodic refresh ... aiming at an area of QSPI attached flash that holds the constant string data for the task names.  I can see the correct task names in the ASCII part of the memory displayed by IAR.

I press the power button on our radio, signalling the application to transition into its full-run mode ... which it starts to do then the applicayion fails.  I can STILL see the memory being refreshed BUT the task names are now mis-reads ...investigating the patterns shows that any ASCII character (well any byte in fact) having bit 2 set displayes incorrectlt since this bit is now clear in EVERY byte in the read flash.

10s later, the WDOG trips and resets the vybrid ... and the refreshing memory display springs back to normal UNTIL I try to push to full-run again,

I can repeat this behaviour ad infinitum.

IF I move some functions from one ,c file into a new ,c file and rebuild ... I do NOT see this behaviour.

Therefore I do NOT believe it can be a functional consequence of our code -- the two builds are functionally equivalent, the difference is in the address assignents that the linker has made in the image.

The relevant QPSI and PLL registers do not change from the OK state to the NOK state.

Could this ne some hard-ti-hit bug in the QSPI processing that takes a program request for memory into a QSPI fetch from the Flash device?  Or an error in the spansion flash chip?

Any thoughts would be appreciated at this stage ... this kind of random error troubles me.

0 Kudos
1,036 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi,

I just thought you were going to try the MQX change I mentioned before.

Is there a way to reproduce that in one our boards? That way I can try to reproduce the issue on my side.

/Alejandro

0 Kudos
1,036 Views
peterwoolley
Contributor III

I don't know what causes it so cannot offer sugestions on how to reproduce ... we have a .elf file that always fails on out system, but it is writtent for out hardware (of course).

0 Kudos
1,036 Views
karina_valencia
NXP Apps Support
NXP Apps Support

alejandrolozano​ can you provide some guidelines and Peter can  work in his side?

0 Kudos
1,036 Views
alejandrolozan1
NXP Employee
NXP Employee

Sure. Peter, would you be nice enough to share the LUT, QSPI configuration and IVT?

Just to make sure it is not a miss-aligned read, please send the linker command file too.

Best Regards,

Alejandro

1,036 Views
karina_valencia
NXP Apps Support
NXP Apps Support

peterwoolley​ can you provide the information requested to continue with the follow up?

0 Kudos
1,036 Views
peterwoolley
Contributor III

qspi_quadspi.o is not in out build ... as I said we don't use the QSPI driver, we are just running an XIP image.

No code that we call can be directly responsible for this effect, so that leaves some issue with memory accesses.

Could a mis-aligned read cause some kind of disruption in the flash reads via QSPI?

0 Kudos
1,036 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi,

Are you booting from QSPI XIP?

Is your application developed in MQX?

Best Regards,

Alejandro

0 Kudos
1,036 Views
alejandrolozan1
NXP Employee
NXP Employee

I ask this because in one version of MQX I faced an expected behavior when booting from QSPI and trying to use the qspi driver of MQX.

I had to modify  the line 898 found  in the file qspi_quadspi.c file of the BSP to this:

quadspi_reg_ptr->BUF3CR =     (quadspi_reg_ptr->BUF3CR & ~QuadSPI_BUF3CR_ADATSZ_MASK)  | QuadSPI_BUF3CR_ADATSZ(128);  /* AHB prefetch size: 128*8byte */

Best Regards,

Alejandro

0 Kudos
1,036 Views
peterwoolley
Contributor III

It is M4 XIP running an MQX based application.

We do NOT use the QSPI driver from MQX at all in our builds ... but I'll check to see if it's included in the kernel build.

The behaviour we see is as if a single bit-per-byte has been masked 'off' ... but this happens at some point AFTER the application has started running.  Is that the symptom (or similar) you have seen?

0 Kudos
1,036 Views
alejandrolozan1
NXP Employee
NXP Employee

The behavior I noticed was that data was not read correctly, not even by the debugger.

/Alejandro

0 Kudos
1,036 Views
karina_valencia
NXP Apps Support
NXP Apps Support

alejandrolozano​ do you have an update?

0 Kudos