I am using an i.MXRT1060 in a custom design but am having boot issues. It should be copying boot code from QSPI memory to OCRAM and executing, but it is failing and dropping to serial. I am not using xpresso stuff but eclipse and would like to know if the source of the internal boot code is available for debugging. I expect the data is getting corrupted in the transfer to memory since the code verifies when loaded into the QSPI flash.
Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
I think I need more information about your design, so I was wondering if you can introduce your testing environment, for instance, a schematic of the board, furthermore, please list the steps of testing in detail.
upload it again.
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.
-------------------------------------------------------------------------------
I am using a Segger J-LINK PLUS IF to JTAG in SWD mode to load and verify boot code. This works fine. I then check serial port 1 for output on reset and only see a Space to Mark change on the transmit line. No data transmission is seen. I think it may be the flash init line of code that is initially loaded that may be wrong but would like to compare the flash content with OCRAM content to see what is transferred. I just need to find where in OCRAM it puts it. I assume this is defined in some ivt file.
Hi,
Thank you for your reply and clarification.
According to your proposal, you want to RT1060 boot from the QSPI flash in NON-XIP mode which consists of the below steps (as the below figure shows).
1) Bootable image is in the external flash.
2) loads the starting 4 KB of data from the bootable image to the internal SRAM (OCRAM). It includes the IVT and BD information and will be used for the application image loading.
3) BootROM transfers the starting 4 KB of data from the internal SRAM (OCRAM) to the destination address space of the bootable image.
4) BootROM continues loading the rest of the bootable image from the external flash to the destination address space and starts up the application binary.
To generate a bootable image to implement the above mode, please refer to the post to do it.
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.
-------------------------------------------------------------------------------
The problem I am trying to solve is why the boot rom is not executing flash code. It is hung in a loop:
0x20001A60 0x20001A5A 0x20001AFC
0x20001A7A 0x20001A5C 0x20001AFE
0x20001A7C 0x20001EF4 0x20001B1E
0x20001A7E 0x20001EF6 0x20001EFA
0x20001A74 0x20001AF8 0x20001A60
0x20001A76 0x20001AFA ...
If anyone has a listing for internal ROM code, what is it looking for??
These previous addresses are in the DTCM. The ROM loop I am seeing is:
0x0020D102 -> 0x0020ED38 ->0020E34C->0x0020E3BA->0x0020E406->0x0020ED48->0x0020D108->
0x0x002173E0->0x0021AA3C->0x002173AE->0x0020D102.
These are all branch points, and am in need of knowing what it is hung on as I cannot find a listing of the internal boot code.
Hello jautry,
your problem may come from the gpio boot overrides. Are they set correctly for your flash or do you burn the necessary eFuses?
At least this was my problem when the cpu (IMXRT1020) was hanging in the boot rom memory area. You can check your boot mode and configuration when it hangs in that memory area with the register view of SRC_SBMR2.
Also see chapter GPIO boot overrides and the table with the Fusemap Descriptions if you are not sure what I'm talking about.
Kind regards,
Stefan
Thanks for the reply. Yes, I thought about that. The values I have are
SBMR1 - 0x00000000
SBMR2 - 0x02000009
These appear correct for NOR flash