QSPI Booting relocation

[samsaprunoff]

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

[samsaprunoff]

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

[jeremyzhou]

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!

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

[samsaprunoff]

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

[dmarks_ls]

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.

[samsaprunoff]

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

[samsaprunoff]

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

[jeremyzhou]

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!

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

[samsaprunoff]

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

[jeremyzhou]

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!

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

[samsaprunoff]

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

[samsaprunoff]

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

[samsaprunoff]

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