topic Re: QSPI Booting relocation in i.MX RT Crossover MCUs

QSPI Booting relocation

samsaprunoff — Thu, 12 Sep 2019 20:35:27 GMT

Good day All,

I am working on a iMXRT1021 custom board that is based upon the RT1021 EVK with the exception that I would like to connect the QSPI Flash to an alternate FlexSPI port. On page 283 of the reference manual it looks like the Rom Bootloader will load from both the FlexSPI "B" and "A" ports, but I cannot find out how to ensure that the system looks to FlexSPI B port. My question is how does the Bootloader know which FlexSPI port to boot from?

Also, the reason I wish to move the QSPI flash to the "B" port, is because I wish to use Uarts 2 and 4 and they occupy the same pins as FlexSPI A.

Thanks in advance!

Cheers,

Sam

Re: QSPI Booting relocation

samsaprunoff — Fri, 13 Sep 2019 01:27:55 GMT

Good day All,

Just a follow up... I found a bit more info in the latest reference manual (I had the previous version) as well as a somewhat related post located here:

https://community.nxp.com/thread/509297

Cheers,

Sam

Re: QSPI Booting relocation

jeremyzhou — Fri, 13 Sep 2019 01:49:03 GMT

Hi,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
It needs no additional configuration except for select secondary pinmux option), the ROM bootloader can detect the FlexSPI interface pin during the boot-up process.

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

Re: QSPI Booting relocation

samsaprunoff — Fri, 04 Oct 2019 18:46:32 GMT

Good day Jeremy,

Thanks again for your post. As a follow up I am having problems programming the QSPI Flash connected on the Secondary Pinmux location. I am using MCUXpresso V 11.0.0 (build2516) with the PEMicro Multilink device. I generated the SDK and can corrected build and program the sample "Hello World" project on the RT1021 EVK. However, if I try this on my custom RT1021 where the QSPI is connected to the secondary pinmux I get the following error:

Executing flash operation 'Program' (Program file into flash: Debug\evkmimxrt1020_hello_world.axf) - Fri Oct 04 12:38:47 MDT 2019
Checking MCU info...
Scanning for targets...
Executing flash action...
P&E GDB Server for Arm(R) devices, Version 7.29.00.00
Copyright 2018, P&E Microcomputer Systems Inc, All rights reserved
Loading library C:\Software\NXP\MCUXpressoIDE_11.0.0_2516\ide\plugins\com.pemicro.debug.gdbjtag.pne_4.1.3.201905161939\win32\gdi\unit_ngs_arm_internal.dll ... Done.
Command line arguments: -device=NXP_iMX_IMXRT1021 -startserver -singlesession -serverport=7224 -gdbmiport=6224 -interface=USBMULTILINK -speed=5000 -port=USB1 -streamingport=10224 -configfile=C:/Users/sam/Documents/MCUXpressoIDE_11.0.0_2516/workspace/.metadata/.plugins/com.pemicro.debug.gdbjtag.pne/config.ini -programmingtype=0 -runafterprogramming -flashobjectfile=C:\Users\sam\Documents\MCUXpressoIDE_11.0.0_2516\workspace\evkmimxrt1020_hello_world\Debug\evkmimxrt1020_hello_world.axf -quitafterprogramming
Config file selected: C:/Users/sam/Documents/MCUXpressoIDE_11.0.0_2516/workspace/.metadata/.plugins/com.pemicro.debug.gdbjtag.pne/config.ini
Device selected is NXP_iMX_IMXRT1021
User Specified Hardware Selection : Interface=USBMULTILINK and Port=USB1
Connecting to target.
P&E Interface detected - Flash Version 6.15
Device is NXP_iMX_IMXRT1021.
Mode is In-Circuit Debug.
(C)opyright 2012, P&E Microcomputer Systems, Inc. (www.pemicro.com)
API version is 101
TARGET XML PATH is C:\Software\NXP\MCUXpressoIDE_11.0.0_2516\ide\plugins\com.pemicro.debug.gdbjtag.pne_4.1.3.201905161939\win32\gdi\P&E\supportFiles_ARM\target_v7m_vfp.xml
Creating kernel driver for freertos
USING V7 DRIVERS WITH M4 OR M7
Server 1 running on 127.0.0.1:7224
Server 2 running on 127.0.0.1:7226
Server 3 running on 127.0.0.1:7228
Server 4 running on 127.0.0.1:7230
Server 5 running on 127.0.0.1:7232
Server 6 running on 127.0.0.1:7234
Server 7 running on 127.0.0.1:7236
Server 8 running on 127.0.0.1:7238
Server 9 running on 127.0.0.1:7240
Server 10 running on 127.0.0.1:7242
Server 11 running on 127.0.0.1:6224
Copyright 2018 P&E Microcomputer Systems,Inc.
Command Line :C:\Software\NXP\MCUXpressoIDE_11.0.0_2516\ide\plugins\com.pemicro.debug.gdbjtag.pne_4.1.3.201905161939\win32\pegdbserver_console -device=NXP_iMX_IMXRT1021 -startserver -singlesession -serverport=7224 -gdbmiport=6224 -interface=USBMULTILINK X
CMD>RE
Initializing.
Target has been RESET and is active.
CMD>CM C:\Software\NXP\MCUXpressoIDE_11.0.0_2516\ide\plugins\com.pemicro.debug.gdbjtag.pne_4.1.3.201905161939\win32\gdi\P&E\supportFiles_ARM\NXP\iMX\issi_is25lp064_1x32x2meg_imxrt1020.arp
Initializing.
Initialized.
;version 1.00, 03/27/2018, Copyright 2018 P&E Microcomputer Systems, www.pemicro.com
;device issi, is25lp064, 1x32x2meg, imxrt1020
;begin_cs device=$60000000, length=$00800000, ram=$00000000
Loading programming algorithm ...
WARNING - Selected .ARP file has been modified. CRC16 = $A94A

Programming sequency is : erase, blank check, program, and verify {default}
CMD>VC
Verifying object file CRC-16 to device ranges ...
block 60000000-60006DB7 ...
Calculated CRC-16 does not match block. (File = $5F8B, Device = $D72B)
Current content of flash does not match application to be programmed
CMD>EM
Erasing.
Module has been erased.
CMD>PM
Programming.
Processing Object File Data ...
.
Programmed.
CMD>VC
Verifying object file CRC-16 to device ranges ...
block 60000000-60006DB7 ...
Calculated CRC-16 does not match block. (File = $5F8B, Device = $D72B)
Error verifying flash of device
Error occured during Flash programming.
All Servers Running
Target Disconnected.

My custom RT1021 PCB has the correct BootConfig pull-downs and pullups (BootConfig[3..1] set to 111) and the QSPI Flash I am using is the same as that on the EVK (S25LP064A-JBLE).

I reviewed the MCUX's debug configuration for the PEMicro and I cannot see any modifications I need to implement to have the flash tool to use the secondary pinmux. Can you tell me if there are changes I need to make in order to program the QSPI device fro MCUX and the PE Multilink device?

Also, I forgot to add that I placed a logic analyzer on my QSPI Flash and I can certainly see activity when the PE Flash tool (from within MCUX) is attempting to program and verify and so it looks like the system knows that the device is present.

Thanks in advance!

Cheers,

Sam

Re: QSPI Booting relocation

jeremyzhou — Tue, 08 Oct 2019 03:35:05 GMT

Hi ,

Thanks for your reply,
According to the error message, it seems that the QSPI has not been recognized, it maybe is related to the hardware circuit.
So I'd like to suggest you use the NXP-MCUBootUtility tool to contact the QSPI to confirm it.

Have a great day,
TIC

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

Re: QSPI Booting relocation

samsaprunoff — Tue, 08 Oct 2019 14:27:52 GMT

Good day Jeremy,

I did try the MCUBootUtility and it also indicates that it cannot connect to the flash device. However, when I place a logic analyzer on the flash pins I see absolutely no activity on any of the pins when the MCUBootUtility is attempting to communication with the flash device. I have tried both the latest version of the MCUBootUtility (Ver 2.1.0) as well as the previous version (2.0.0) and I am seeing the same results. Interestingly, if I set the bootmode to internal boot and reset the RT1021 the logic analyzer does see activity on the serial flash interface pins and so it would appear that the RT1021 can signal the serial flash device.

I do know that the MCUBootUtility is connecting and reading various internal registers of the RT1021, as I can see the data retrieved from within the "device status" window.... so I know the MCUBootUtility looks to be interacting with the RT1021 device to some degree.

Here are some screen shots of how I have configured the MCUBootUtility... as perhaps I am doing something incorrectly?

When I click the "reconnect" button I get the following

Cheers,

Sam

Re: QSPI Booting relocation

samsaprunoff — Tue, 08 Oct 2019 16:10:08 GMT

Good day All,

As a follow up to my previous response...

As I mentioned I am seeing no logic activity between the RT1021 and the flash device when using the MCUBootUtility and when the RT1021 bootmode is set to serial boot mode (e.g. BootMode set to "01"). However, if I set the BootMode to "10" (internal boot), MCUBootUtility now creates logic activity between the RT1021 and the flash device. Also the logic activity is way more comprehensive than simply what I saw from a reset and so the MCUBootUtility is certainly doing something. Given this latest info I am starting to think that the MCUBootUtility has a bug with the RT1021 with a flash connected to the Secondary PinMux.

Can anyone confirm if they have been able to successfully use the MCUBootUtility with the R1021 connected to the flash on the Secondary Pinmux? If so, what version of the MCUBootUtility was used?

Thanks in advance!

Cheers,

Sam

Re: QSPI Booting relocation

jeremyzhou — Wed, 09 Oct 2019 03:24:08 GMT

Hi ,

Thanks for your reply.
I'll contact the author of the MCUBootUtility to confirm your inquiry, however, I was wondering if you can share the schematic of your custom board, it may give me a new insight into the issue.

Looking forward to your reply.

Have a great day,
TIC

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

Re: QSPI Booting relocation

samsaprunoff — Wed, 09 Oct 2019 20:12:31 GMT

Good day Jeremy,

I will post the schematics shortly, however, they are pretty much the same as the RT1021 EVK except for relocating the flash memory to the secondary pinmux and adding pullups in bootconfig[3..1] pins (GPIO_EMC_21...GPIO_EMC_19). I have also confirmed and measured the voltages on all of the BootConfig pins to ensure that they are set to the correct levels. In my case they are:

BootConfig[9..4] = set to 0

BootConfig[3..1] = set to 1

BootConfig[0] = 0

What I find interesting is that I see no logic activity on the secondary pinmux flash connections out of reset when bootmode is set to serial download. This is in contrast to when bootmode is set to internal boot, as here there is logic activity on the secondary pinmux flash connections out of reset. Can you confirm this? This would certainly explain why MCUBootUtility fails to locate my serial flash device when the RT1021 is set to serial bootloader... Unless something is serious wrong with my circuit or my particular two RT1021 devices (I have assembled 2 PCBs), it would appear that the secondary pinmux is ignored and/or the bootconfig [3..1] are ignored in serial bootloader mode.... Can you confirm this as well?

Cheers,

Sam

Re: QSPI Booting relocation

jeremyzhou — Tue, 15 Oct 2019 08:08:24 GMT

Hi ,

After contact with the AE team, we consider the issue is mainly related to the hardware circuit and you'd better share the schematic of your custom board with us.

Have a great day,
TIC

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

Re: QSPI Booting relocation

samsaprunoff — Tue, 15 Oct 2019 15:24:51 GMT

Good day Jeremy,

Thank you for your post. I will post the schematics later today. However, can you answer my questions I presented in my previous posts:

Question 1: Do you have any customers that successfully used the MCUBootUtility (latest rev) with the R1021 connected to the flash on the Secondary Pinmux?

Question 2: Can you tell me if there should be any logic activity on the flash pins (any of them) out of reset when the flash is connected to the secondary pinmux and the processor is set to serial bootloader mode?

Question 3: Can you tell me if Bootconfig[3..1] are read by the processor when the processor is set to serial bootloader mode?

Thanks in advance!

Cheers,

Sam

Re: QSPI Booting relocation

dmarks_ls — Tue, 15 Oct 2019 17:55:42 GMT

Hi Sam,

I see that you're also using the alternate QSPI pinout (I'm using an RT1052). I've got mine working OK, using the same QSPI flash device (IS25LP064A). For the MCU Boot Utility, in addition to picking the IS25LPxx part, selecting Option1, and selecting Has Secondary Pinmux, you also want to select "Quad Mode Setting: Set StatusReg1[6]". That's the Quad Enable bit in the status register. Why it's not defaulted for this device type, I don't know.

Try that, and when you click the button to "Connect to ROM", it should go yellow, then green, then blue, with no warning dialogs.

David R.

Re: QSPI Booting relocation

dmarks_ls — Tue, 15 Oct 2019 18:46:35 GMT

Hi Sam,

I can answer two of your above questions for you. Question 1... yes, I'm using QSPI on the alternative pinmux. See my comment above this one that has the MCU Boot Utility settings I use with my RT1052 and IS25LP064A QSPI flash on the secondary pinmux location.

Question 2... I rather suspect there should be some activity when the serial bootloader starts. There should also be activity if you've selected Internal Boot. Based on my own experiences trying to get a different model of QSPI flash to work (before giving up and just using the IS25LP064A), I strongly suggest that you make sure you've got your bootstrap settings correct.

On our custom RT1052 Rev. A board, we fully replicated the boot select switches that are found on the RT1050 EVKB. Here's a snap of the schematic page:

And here's an annotated copy of the BOOT_CFG[11:0] and BOOT_MODE[1:0] bit definitions:

Please note... the 12 boot switches do not correspond directly to the 12 BOOT_CFG bits. For my BOOT_CFG[11:0], the only bits I have to set are bits 8, 9, and 10. Here's what my boot switches look like properly configured:

Selecting the secondary pinmux requires setting SW3-3, SW3-4, and SW4-2 (as pictured above). The last two switches correspond to the boot mode. On the RT1050, BOOT_MODE = 01 selects Serial Downloader, and BOOT_MODE = 10 selects Internal Boot. So above, the board is selecting Internal Boot. Note that on the RT1050 EVKB, the first two banks of switches are depopulated, partly because one is expected to use the 1.8V HyperFlash.

You should be able to set your board for internal boot off your secondary pinmux, and after powerup/reset, you should see activity on your QSPI pins. If you don't, your bootstrap settings are not correct. Look at your boot pins and your high/low pull resistors; the only pins that should be pulled high are BOOT_CFG[8], BOOT_CFG[9], BOOT_CFG[10], and BOOT_MODE[1] (for internal boot); all others should be pulled low.

If you are getting signs of life on QSPI when you reset your board in internal boot mode, then that's a good sign that FLASH_TYPE has been successfully strapped to 111. Once that's working, try switching to serial downloader mode, set all of the config options I show above, and see if that works for you.

David R.

Re: QSPI Booting relocation

samsaprunoff — Tue, 15 Oct 2019 21:05:07 GMT

Good day David,

Thank you for your post! Indeed, I saw, read, reread, etc your original thread as this gave me some info and direction on my issue(s). I will have to try the quad mode setting, as I simply used the defaults.

In my case I only got the yellow, green, and blue MCUBootUtility indicator only when I set the bootmode to internal boot, as serial bootloader would not connect at all to the flash... which I used the same flash type as the RT1021 EVK.

Cheers,

Sam

Re: QSPI Booting relocation

samsaprunoff — Tue, 15 Oct 2019 21:29:04 GMT

Good day again David,

Within regards to my question 1, the variable that is different is that I am using the RT1021 and not the 1052 and so I was curious if anyone had successfully used MCUBootUtility with the RT1021 and the flash on the secondary pinmux. So, far I have be unable to find anyone that has. Dave Marples who responded to your thread has been a great help. In his case he is using a j-link for connection to his RT1021 and flash and this combination has been successful. Sadly, my j-link is too old and so it cannot communicate with the RT1021, as the j-link tells me this. I have another and newer j-link on its way just to see if this will work.

What is interesting is that the MCUBootUtility and enabling the secondary pinmux configuration settings seem to have no effect on the RT1021EVK with its flash connected to the primary location. I say this, as MCUBoot programs the EVK's flash properly even with pinmux set to yes, etc.

As for the BootConfig values... on the RT1021 the flash settings are BootConfig[3..1] and so are different than on the 1052. I have double, triple, etc checked the bootconfig settings on the pins and they are as expected. I actually measured the voltages right at the RT1021 pins to be sure. I was looking for an internal register that I could read to verify that the processor has indeed read the bootconfig values, but alas I have been unable to find any such register.

As another test I even removed the programmed flash on the EVK and used it on one of my boards and it worked fine (connected to the secondary pinmux location)... and the example program ran. So, it would appear that the flash is "seen" by the processor and will boot. However, after trying to program this replaced flash via MCUBoot on my custom PCB the original problem would manifest itself... and I am back at square 1.

Given the above and various tests I have done it seems that that processor is either not being reset properly and/or something is placing it in a very odd mode. I am reviewing my reset circuit to see if there are any oddities about it and so far I have not found anything. The only item that I notice that is different is that my custom PCB has a lower Vdd_SOC_In voltage than the evk. The RT1021EVK Vdd_Soc_In measures 1.25V whereas on my PCB I am measuring 1.15V. The datasheet states that the voltage range should be between 0.925V and 1.3V and so my value appears in the valid range. As I said, this so far as been the only real difference I can find.

I will post up the schematics shortly, as Jeremy wants to review them to be sure. I followed the Rt1021's EVK schematics and they match except the flash connections and a different reset device (but has the same specs).

Cheers,

Sam

Re: QSPI Booting relocation

samsaprunoff — Tue, 15 Oct 2019 22:47:34 GMT

Good day Jeremy,

My apologies for taking so long getting the schematics, but I was called away several times today.

I also note that my +3.3V power supply has a max current capability of 3A. It is a switcher and has a measured ripple of approximately 7mV. I did try connecting to a +3.3V bench linear supply with no change to the results.

I did not include my USB to Serial converter circuit connected to UART1... as this simply a FTDI part and I am not connecting to it... I am using MCUBootUtility on the direct USB Interface to the RT1021.

Cheers,

Sam

Re: QSPI Booting relocation

jeremyzhou — Wed, 16 Oct 2019 11:06:42 GMT

Hi ,

Thanks for your reply.
After reviewing the schematic, I also haven't found the error in the connection of QSPI flash.
In further, you said you do this kind of testing: removing the programmed flash on the EVK and used it on one of my boards and it can boot up successful and works fine (connected to the secondary pinmux location). In my opinion, it can tell that the hardware circuit of connecting the QSPI is correct.
About the MCUBootUtility, I'll contact the Heng Jie who is the author MCUBootUitilty to clarify your inquiry later.
Now, I have another idea with further validate the hardware circuit, there's flexspi_nor_polling_transfer demo in the SDK library, please run the demo in the internal RAM to operate the external Nor flash via the FlexSPI module, note that: it needs the adapt the pin configuration in the BOARD_InitPins(); for secondary pinmux option.

TIC

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

Re: QSPI Booting relocation

samsaprunoff — Wed, 16 Oct 2019 14:38:04 GMT

Good day Jeremy,

Thank you for your response and for reviewing the design.

Indeed, I can get the design to boot if I preprogram the flash on the EVK and then mount the device to my PCB. Although this sort of works there are still issues, as I am unable to debug or program the atttached flash via the JTAG Port usig MCUXpress (latest version). I know that the MCUXpress and my JTAG debugger work, as I am able to program and debug the EVK's flash without issue. Secondly, I have tried several debuggers (PEMicro, LPC-Link, etc) and all have the same results on my board... and so something is still amiss. The only thing left for me to try is to replace the processor itself. I have production RT1021's arriving in a few days and so I will try one of these.

Also, can you comment on my Vdd_soc_in voltage measurement? I ask, as I am reading a lower voltage on this rail (1.15V) as compared to the EVK which was 1.25V. The datasheet does indicate that my measurement is in the correct range, but was curious if a lower internal core voltage could cause strange behavior of the processor... and I am seeing strange behavior.

Lastly, can you tell me if there is an internal register I can read that can tell me what the processor's BootConfig values were out of reset? I could only find the fuse values for BootConfig, but nothing that denotes an active register. Although I have measured the voltages at the processor's pins of the external BootConfig overrirde values I would like to confirm that the processor actually read the same logic levels I have measured. If there was a register then I can retrieve its values from MCUBootUtility, as this utility reads and displays internal registers on my PCBs without issue.

Lastly, I will review the other demo software you mentioned and try and get it working on my design.

Thanks again for your assistance!

Cheers,

Sam

Re: QSPI Booting relocation

samsaprunoff — Thu, 17 Oct 2019 02:19:53 GMT

Good day Jeremy,

You can disregard my question about the Vdd_Soc_In voltage, as I found my answer on Page 20 of the iMXRT1020CEC Document... If the processor is in idle mode, Vdd_soc_in will be between 1.15 to 1.3V ... and so my value is correct.

Also, I did try and operate the demo program (evkmimxrt1020_flexspi_nor_polling_transfer), and although it runs out of RAM it trys to program the flash as part of the download and so it fails... as it cannot program the flash memory and responds with an error:

And here is the information from the debugger console:

MCUXpresso IDE RedlinkMulti Driver v11.0 (Aug 27 2019 16:46:33 - crt_emu_cm_redlink build 22)
Found chip XML file in C:/Projects/MCUXpresso/evkmimxrt1020_flexspi_nor_polling_transfer/Debug\MIMXRT1021xxxxx.xml
Reconnected to existing LinkServer process.
============= SCRIPT: RT1020_connect.scp =============
RT1020 MPU Disable
Finished
============= END SCRIPT =============================
Probe Firmware: LPC-LINK2 CMSIS-DAP V5.224 (NXP Semiconductors)
Serial Number: JXBUFYAT
VID:PID: 1FC9:0090
USB Path: \\?\hid#vid_1fc9&pid_0090&mi_00#8&34ee1063&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Using memory from core 0 after searching for a good core
debug interface type = Cortex-M7 (DAP DP ID 0BD11477) over SWD TAP 0
processor type = Cortex-M7 (CPU ID 00000C27) on DAP AP 0
number of h/w breakpoints = 8
number of flash patches = 0
number of h/w watchpoints = 4
Probe(0): Connected&Reset. DpID: 0BD11477. CpuID: 00000C27. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Content of CoreSight Debug ROM(s):
RBASE E00FD000: CID B105100D PID 000008E88C ROM (type 0x1)
ROM 1 E00FE000: CID B105100D PID 04000BB4C8 ROM (type 0x1)
ROM 2 E00FF000: CID B105100D PID 04000BB4C7 ROM (type 0x1)
ROM 3 E000E000: CID B105E00D PID 04000BB00C Gen SCS (type 0x0)
ROM 3 E0001000: CID B105E00D PID 04000BB002 Gen DWT (type 0x0)
ROM 3 E0002000: CID B105E00D PID 04000BB00E Gen (type 0x0)
ROM 3 E0000000: CID B105E00D PID 04000BB001 Gen ITM (type 0x0)
ROM 2 E0041000: CID B105900D PID 04001BB975 CSt ARM ETMv4.0 type 0x13 Trace Source - Core
ROM 2 E0042000: CID B105900D PID 04004BB906 CSt type 0x14 Debug Control - Trigger, e.g. ECT
ROM 1 E0040000: CID B105900D PID 04000BB9A9 CSt type 0x11 Trace Sink - TPIU
ROM 1 E0043000: CID B105F00D PID 04001BB101 Sys (type 0x0)
NXP: MIMXRT1021xxxxx
DAP stride is 1024 bytes (256 words)
Inspected v.2 External Flash Device on SPI MIMXRT1020-EVK_IS25LP064.cfx
Image 'MIMXRT1020-EVK_IS25LP064A Aug 27 2019 15:37:25'
Connected: was_reset=true. was_stopped=false
Awaiting telnet connection to port 3331 ...
GDB nonstop mode enabled
Opening flash driver MIMXRT1020-EVK_IS25LP064.cfx
Sending VECTRESET to run flash driver
Flash device supported (8MB = 128*64K at 0x60000000)
Writing 34040 bytes to address 0x60000000 in Flash
driver "EraseSector" timeout (6000 ms) PC: 20000808
There was a problem after a flash driver operation timed out, so we are going to compare the flash driver code with the memory where it was loaded.
Note that, after driver initialization, some difference is normal in 'generic' drivers.

Driver from AXF file:
200011E0: 11b3dc40 00000000 00000000 @...........
Driver code in memory:
200011E0: 1dcd6500 016e3600 00008000 .e...6n.....
Closing flash driver MIMXRT1020-EVK_IS25LP064.cfx
Target error from Commit Flash write: Ec: Flash driver "EraseSector" timeout (6000 ms) PC: 20000808
GDB stub (crt_emu_cm_redlink) terminating - GDB protocol problem: Pipe has been closed by GDB.

Cheers,

Sam

Re: QSPI Booting relocation

jeremyzhou — Thu, 17 Oct 2019 11:19:22 GMT

Hi ,

Thanks for your reply.
Please follow the steps to configure the evkmimxrt1020_flexspi_nor_polling_transfer demo project, then give a try again.
Note that: it needs the adapt the pin configuration in the BOARD_InitPins(); for secondary pinmux option.

TIC

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