topic Re: QSPI0 Flash Mis-read in Vybrid Processors

QSPI0 Flash Mis-read

peterwoolley — Thu, 30 Apr 2015 16:32:42 GMT

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?

Re: QSPI0 Flash Mis-read

alejandrolozan1 — Tue, 05 May 2015 21:21:02 GMT

Hi,

Are you booting from QSPI XIP?

Is your application developed in MQX?

Best Regards,

Alejandro

Re: QSPI0 Flash Mis-read

alejandrolozan1 — Tue, 05 May 2015 21:31:38 GMT

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

Re: QSPI0 Flash Mis-read

peterwoolley — Wed, 06 May 2015 11:30:30 GMT

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?

Re: QSPI0 Flash Mis-read

alejandrolozan1 — Mon, 11 May 2015 17:34:50 GMT

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

/Alejandro

Re: QSPI0 Flash Mis-read

karina_valencia — Fri, 15 May 2015 17:14:22 GMT

alejandrolozano do you have an update?

Re: QSPI0 Flash Mis-read

alejandrolozan1 — Sat, 16 May 2015 16:47:12 GMT

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

Re: QSPI0 Flash Mis-read

peterwoolley — Sat, 16 May 2015 20:00:35 GMT

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.

Re: QSPI0 Flash Mis-read

alejandrolozan1 — Sat, 16 May 2015 23:57:21 GMT

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

Re: QSPI0 Flash Mis-read

peterwoolley — Mon, 18 May 2015 10:29:20 GMT

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?

Re: QSPI0 Flash Mis-read

peterwoolley — Mon, 18 May 2015 10:30:27 GMT

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).

Re: QSPI0 Flash Mis-read

karina_valencia — Mon, 08 Jun 2015 21:38:54 GMT

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

Re: QSPI0 Flash Mis-read

alejandrolozan1 — Mon, 08 Jun 2015 21:44:44 GMT

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

Re: QSPI0 Flash Mis-read

karina_valencia — Mon, 15 Jun 2015 16:19:03 GMT

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

This an automatic process. We are marking this post as s...

CommunityBot — Thu, 03 Sep 2020 16:31:31 GMT

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!