How can I debug the internal boot process on the i.mx RT 1020?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How can I debug the internal boot process on the i.mx RT 1020?

1,769 Views
henrique1
Contributor III

Hi!

We've developed a custom board using the i.mx RT1020 chip and it's giving us some trouble with the boot sequence.

The design is based on the MIMXRT1020 development board (all the relevant systems are an exact replica of the original design), and so we'd like it to boot from the QSPI NOR flash. The boot config pins are set to the default low (BOOT_CFG[7:0]) and the boot mode is set to internal boot (BOOT_MODE[1:0] = 0b10).

We're using the J-link base as an external probe, and when trying to run the example program 'evkmimxrt1020_iled_blinky'. The flashing process appears to be successful but then it seems that the program gets  stuck on the BOOT ROM region. When appyling this same exact process on the evk board, everything works as expected.


Does anyone have any suggestions on how to go about finding the core reason behind this issue? Ideally it would be nice to know from the bootrom program flow exactly which part of the process is failing, but I don't know if that's possible. I've ordered an USB2UART adapter to be able to communicate with the board through the 'serial downloader' protocol, but for now that's still not an option.

Thanks!

Henrique

Labels (1)
5 Replies

1,492 Views
henrique1
Contributor III

Hey jeremyzhou‌!

Thank you for your answer, I think you are right! It does work if I "flash" the program directly to OCRAM.

However I've replaced the QSPI flash chip and still get the same behaviour, so there my be some other obscure hardware issue. Atm I'm still unable to interface it with UART so the second option is still unavailable to me. I wonder however why I get a successful flash download, shouldn't this operation fail as well if it is the case that something's wrong with the external flash?

0 Kudos

1,492 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Henrique Nogueira,

Thanks for your reply.
According to your reply, flexspi_nor_polling_transfer can work well on your board, if that, we can assure the QSPI flash hardware connection is correct.
I don't agree with the suggestion from, as I use the J-link Plus to debug the MIMXRT1020 board via the J16 to emulate your case (Fig1),  however, it can enter the debug mode successfully without enabling QE bit manually.
You can try using the MIMXRT1020_SFDP_QSPI.cfx (Fig2) if you encounter this error: kStatus_FlexSPINOR_SFDP_NotFound.

pastedImage_2.pngFig 1

pastedImage_1.png

Fig 2


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

0 Kudos

1,492 Views
henrique1
Contributor III

Hi jeremyzhou,


As mentioned in the thread this is only an issue with custom boards. It's true that the EVKs are good to go out of the board and there's no need to manually enable the flash IC's QSPI Enable bit, which is persistent. When the EVKs are programmed with the default program, this bit is probably being set.
This is the best explanation I've found so far and explains why the system started working only after running the flexspi_nor_polling_transfer example program and not before.

Henrique

0 Kudos

1,492 Views
henrique1
Contributor III

I stumbled upon this thread where I learned about the SDK example that tests the QSPI flash system. Similarly to some of the people posting on that thread, after having ran the program using only RAM, everything seems to be working now, but I don't really understand the reason why.

0 Kudos

1,492 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Henrique Nogueira,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
According to your statement, I suspect that this issue is related to the hardware connection with the QSPI flash chip, so I'd like to try these two methods to confirm.
1. Try to debug the evkmimxrt1020_iled_blinky demo in RAM area instead of the external flash.
2. Try to program the QSPI via the Serial Downloader as the AN12108:
How to Enable Boot from QSPI Flash illustrates.


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