Hello!
We have developed a custom PCB based on the IMXRT1176 MCU, utilizing the same QSPI Flash as the IMXRT1170-EVK evaluation board. I am currently working on running a simple "blinky" application on the board.
Using the sample from the SDK, I modified the LED to GPIO13, IO7. The application works as expected when executed from internal RAM (by linking the application to RAM) within the MCUXpresso IDE, and I am able to debug without any issues. However, when attempting to run the application from external flash, I encounter difficulties. Specifically, I am unable to debug using the J-Link interface. I have also set the boot mode to [10] for internal boot, but the problem persists.
I have attached some screenshots for your reference and would appreciate any guidance you could provide on resolving this issue.
While debugging I get this deadbee error and no LED glows.
This is the Jflash window showing that the boot header was added properly by the MCUXpresso .
Hi @apoorv
I seem to be having the exact same issue as you described. Were you able to find a solution or the root cause of the issue?
Thanks in advance!!
I'm having the exact issue that you guys are having. The issues only happen when I'm debugging. Did you find any resolve?
What debug probe are you guys using?
Hello, thanks for the reply.
I have utilized the secure provisioning tool with the iled_blinky_cm7 example from the SDK, ensuring that the boot header is disabled (XIP_BOOT_HEADER_ENABLE=0). I've attached the zipped project for your reference.
Additionally, I've included the boot configuration and FCB configuration stored in the flash.
Despite these efforts, the device is still not booting, and the LED is not blinking as expected.
Hi @apoorv,
I tested the application you shared (only changing the LED to GPIO9, pin 3) and it worked as expected when running from flash and in internal boot mode, being able to even start a debug session and run through it step by step.
Perhaps the issue is HW related rather than SW?
BR,
Edwin.
Hello,
Thank you for your response. We'll test the hardware and check the SPI signals during boot-up.
I'd also like to point out something that might help guide us. When I run the flexspi_nor_polling_transfer_cm7 example (loading the application to RAM using Link), I notice a mismatch between the bytes written and the bytes read:
--------------------------------------------
FLEXSPI example started!
Vendor ID: 0x9d
Erasing Serial NOR over FlexSPI...
Erase data - successfully.
Program data - read out data value incorrect !
--------------------------------------------
But when I change the
from .ARDSeqIndex = NOR_CMD_LUT_SEQ_IDX_READ_FAST_QUAD,
to .ARDSeqIndex = NOR_CMD_LUT_SEQ_IDX_READ_NORMAL,
the application runs successfully, and the read/write bytes match.
----------------------------------------
FLEXSPI example started!
Vendor ID: 0x9d
Erasing Serial NOR over FlexSPI...
Erase data - successfully.
Program data - successfully.
----------------------------------------
Could this indicate where the problem lies? Do you have any suggestions on what aspects of the hardware I should focus on?