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?
