Unable to execute in XIP mode

[jautry]

I have two proto boards, and I can run the SDK flexspi_nor_polling_transfer program on both successfully.  When I try to run the enet_rxtx_transfer program, one works, one does not.  It appears one of the boards never makes it out of the internal bootloader while trying to operate in XIP.  The SBMR registers are both identical, the SEC_CONFIG both the same, (Open), and of course the code is the same, so I am currently at loss as to what could cause this.  Checking whether anyone else has run into this.

[jeremyzhou]

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
According to your statement, one board works well, another one fails, it's obviously related to the hardware circuit.
Moreover, it's hard to jump to the conclusion that the board doesn't support the run in XIP mode just based on a demo fail to run.
Anyway, I'd like to suggest you check the hardware circuit first.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[jautry]

You are correct, it must be in hardware, just out of ideas where.  The correct values for the SBMR registers indicate boot configs are correct.  The QE bit is also set on the flash and the flash processor interface works fine on the flexspi program.  The FCB is being read by the processor as I see the settings changes in the processor registers so not sure why internal bootloader is kicking it out.  The only thing I can think now is that it must be a faulty flash for some reason.

[jeremyzhou]

Hi,
Thanks for your reply.
Whether you ever try other demos in the SDK library and do the demos replicate the same phenomeon?
Regarding your assumption, I'd like to suggest you replace a new flash to verify.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[jautry]

Ok, I replaced both the flash and the processor and have the same problem.  What is externally unique to XIP mode that could affect XIP operation.  I thought it was purely between the processor and flash.

[jeremyzhou]

Hi,
Thanks for your reply.
1) What is externally unique to XIP mode that could affect XIP operation. I thought it was purely between the processor and flash.
-- The board contains the power supply, clock, reset circuits besides the MCU and QSPI, these portions also affect the boot-up actually.
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[jautry · Accepted solution]

Ok, I got the unit operating in XIP.  Turns out it was multiple issues confounding the main issue.  I use the flexspi_nor to test flash and set QE bit.  In my system I was using A1 and A2 flash so I added both devices to the test program.  Apparently, the FLEXSPI_SetFlashConfig can only be called once.  I called it with the A2 port after calling with the A1 port.  This overrides the port designation and any call to a function (vendor ID, Set Quad Mode) is routed to the A2 port so the A1 never was being accessed.  When I read the status for A1 indicating QE set, I was physically looking at the A2 port so A1 was never being set.  This probably makes sense due to the fact the SetConfig sets the AHB to the last port config called which was A2.

[jautry]

I agree these are common components, but the fact that evkmimxrt1060_flexspi_nor_polling_transfer sdk program works perfectly tends to eliminate them and is something specific to XIP operation.