U-Boot to MQX transition disables QSPI

[tfe]

We are working on a custom card, and are trying to boot MQX from a QSPI SFlash (S25FL256SAGMFIR0) using a modified version of U-Boot (based on this tutorial: TWR-VF65GS10).

U-Boot starts fine, loads the MQX app from the SFlash and starts the app. The app is then supposed to run its own init. routines before doing it's primary tasks. However, the MQX app gets stuck in an infinite loop, waiting for the QSPI busy-flag to de assert:

while (quadspi_reg_ptr->SR & QuadSPI_SR_BUSY_MASK);

This does not happen when running the same MQX app from ARM DS-5 using the ULINKpro D Debugger. That is to say, everything works fine when using the debugger.

After probing the data-lines of the SFlash-chip, we found that there is no activity on any IO-lines, the CS or the SCK. Using the debugger to break on the QSPI/SFlash init-routine after U-Boot has loaded the MQX app, shows that all appropriate registers are being written to, but there are no corresponding activity on said data-lines.

The SFlash works fine in the U-Boot HUSH-shell, and have been confirmed using the "sf"-command.

We have also attempted to disable the IOMUX-setup in the MQX bsp without any luck.

The strangest part of this issue is that another custom board, which is near-identical in regards to the SFlash/QSPI-part (same SFlash-chip, pinout, etc), do not show the same symptoms. I.e. everything works fine. The two boards also share the same QSPI/SFlash-drivers.

Does anyone know what might cause this peculiar behaviour?

[CommunityBot · Accepted solution]

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!

[karina_valencia]

tfe​ did you get previous update?

[rendy]

Hi,

- where exactly in the MQX code is the 'while' located?

- do you use QSPI XIP or do you copy the program into RAM and run it there?

- are you sure that debugger target is QSPI? Don't you debug from RAM?

Regards

Rene

[tfe]

My apologies for the late response. It seems I did not get an email notification with your response.

We do not use QSPI XIP.

The issue seems to have resolved itself. It happened after disabling PLL3 and PLL5 in U-Boot. We however do not understand why this change fixed our issue.

/Tom