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

[beejesh_ag1]

Dear Sam & David,

Thanks a lot for your valuable comments on this.

Sorry for not to mention that boot configuration GPIOs I have taken care already and trying to boot from internal BT_MOD 2'b10.

And glad to see device started to boot from QSPi after flashing example binary provided along with NXP-MCUBootUtility.

Even with MCUXpresso it worked fine using PE micro deugger.

Curious to know, Why MCUXpresso flashing tool don't take care this boot info in flash, Or what stop it doing so.

I assume bootloader fail to setup FLexSPI flash interface and later PE micro too communicate to same. Please correct if Im wrong.

Thanks again for your time and help.

regards,

BEEJESH

[beejesh_ag1]

Hi Sam,

Im on debugging my custom board with MIMXRT1021CAG4A - 400MHz and IS25LP064-JBLE flash.

I have connected as is in EVK board , Still I'm facing to boot from this chip.

I see all data 0x00s in disassembly view on MCUExpresso and goes to hard fault when I do Run.

Board is working when i dump code into RAM but from flashing to Flash.

Do I need to do any special thing to enable it for QPI mode? I suspect HOLD pin of flash chip block it from bootloader trails. BTW I can see 33Mhz activity on Clock and SO pins. but nothing in response from flash.

regards,

BEEJESH

[dmarks_ls]

I second what Sam says.  It looks like you have your flash wired correctly to the FlexSPI bus.  You need to make sure that you have the RT1021 bootstrap jumpers set correctly.  On the RT1052, there are 12 BOOT_CFG bits on GPIO_B0_04-15, which are the first 12 bits of the LCD bus, plus two BOOT_MODE bits on GPIO_AD_B0_04-05.  On the RT1021, there are 10 BOOT_CFG bits on GPIO_EMC_18-27, plus two BOOT_MODE bits on GPIO_EMC_16-17.  You need to make sure that these bits (pins) are pulled up or pulled down according to how your system needs to boot.  For instance, I had to pull up BOOT_CFG_08-10 (also called BOOT_CFG2[2:0]) on my RT1052 because I was booting from QSPI on the secondary pinmux.  On the RT1021, BOOT_CFG1[3:1] controls which type of serial NOR flash you boot from; I'm pretty sure your setting would need to be 000b.  Probably all of your BOOT_CFG pins need to be pulled down to zero, if the default values work for your board.  You also need to set BOOT_MODE correctly; for "internal boot", you want BOOT_MODE1 (GPIO_EMC_17) pulled high, and BOOT_MODE0 (GPIO_EMC_16) pulled low.

You need to look at Tables 8-2, 8-8, and 8-9 in the RT1020 Reference Manual to verify that you have the correct boot options selected.  You also need to make sure that you do not have any devices or passive components driving those pins while the RT1020 is in power-on reset, except for your pull-down/pull-up resistors.  Those pins are chosen as bootstrap pins because in most use cases (e.g. driving an LCD controller with an RT1050), those pins are normally configured as outputs and are thus tri-stated during reset.  Make sure you have not assigned any input functions to those pins that would interfere with system boot.

David R.

[samsaprunoff]

Good day Beejesh.

You need to ensure that your have the correct pull-ups or pull-downs installed on the various RT1021 I/O pins so that the RT's internal boot rom knows what and where you wish to boot from.  The EVK provides an excellent example of this and I find that I continue to use small dip switches like the EVK in case I wish to boot from other sources (e.g. SD Card, etc) on my custom hardware.

Secondly, the QSPI flash needs to be initialized with bits of info too.  On a "fresh" unprogrammed board I use the free MCUBootUtility that was created and maintained and connect to the USB interface.   You can search on here for info and links to this utility. 

Once this QSPI flash is initialized, etc then I can download and program the QSPI directly from MCUXpresso assuming I have the BootMode pins set appropriately.... I have tested the PEMicro and the LPC-Link2 debug pods and both work fine.  I prefer the LPC-Link2, as downloading, programming, and debugging  appear faster.  ... plus the LPC-Link2 is a lot cheaper than the PE device.

As for your firmware... I would try and download and program one of the example and basic applications.  This will ensure remove any firmware oddities as being the problem. 

I hope the above helps.

Cheers,

Sam

[dmarks_ls]

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.

[samsaprunoff]

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

[jeremyzhou]

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!

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

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

[samsaprunoff]

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

[jeremyzhou]

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!

- 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 again Jeremy,

I did more testing and debugging and did the following:

1. I removed and replaced the processor to rule out the processor being damaged. The "new" processor works the same as the previous processor.

2. To rule out any soldering issue with the pull ups/downs on the Boot Config pins, I soldered shorting wires to force the pins to their respective state (BootConfig [3...1] set to 1, Other BootConfig pins set to 0).  The result was no change .

3. I created a simple LED Blinking program and linked it to run only in RAM.  I was able to successfully download and run the program on both of my target PCBs via the JTAG port using LPC-LINK2.  Pausing and Single stepping through the program worked as expected.  This does confirm that the processor and the JTAG interface are working as expected... well with regards to downloading and running out of RAM anyway.

4. I checked all the processor voltages and all appear in the normal range.

5. I replaced my Reset supervisor with a open drain version (I originally used a push-pull version) and no change was noted.

6. I connected an external Linear 3.3V power supply to the PCB to rule out the on-board 3.3V power supply.  No change was noted.

Cheers,

Sam

[jeremyzhou]

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!

- 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 was reviewing my design and the EVK and one thing that is different is the way that Vdd_snvs_in is powered.  The RT1021CEC document on Page 24 Section 4.2.1.1 states:

VDD_SNVS_IN supply must be turned on before any other power supply or be connected
(shorted) with VDD_HIGH_IN supply.

On the EVK the "Vdd_snvs_in" pin is supplied power first and this looks to assert the pmic_on_req pin, which enables the +3.3V supply for the rest of the processor.  This agrees with the above statement in that the Vdd_snvs_in pin has power applied first.  On my design I have the Vdd_snvs_in and the Vdd_high_pin connected/shorted together which is the latter portion of the above statement.  Is it possible that the statement is incorrect and that for a correct processor boot/startup that only the first case (e.g. Vdd_snvs_in must be powered for some period of time before anything else) is valid?  If so then this could explain why my design's processor seems to boot in a strange way...e.g. not reading the bootconfig pins properly?

Can you check into this to see if my comments have any merit?  Sadly, I cannot easily test this on my board, as the vdd_snvs_in pin cannot be easily removed from its connection.... and the EVK has unpopulated 0402 resistors in various areas which make it hard to hand rework... although I will try.

Cheers,

Sam

[jeremyzhou]

Hi samsaprunoff,

Thanks for your reply.

1) Is it possible that the statement is incorrect and that for a correct processor boot/startup that only the first case (e.g. Vdd_snvs_in must be powered for some period of time before anything else) is valid?
-- No, Vdd_snvs_in's okay to connected (shorted) with VDD_HIGH_IN supply.
2) There are no registers to reflects the currently used/read the values of the Boot Config pins.
3) Regard to debug evkmimxrt1020_flexspi_nor_polling_transfer, the consequence seems a bit weird.

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 the response delay!

Thank you for the additional information!  I have been working with your office in Texas and they have discovered a few things with regards to the issues I am seeing.  The first is that the MCUBootUtility looks to have a bug with programming the flash on the secondary Pinmux.  NXP in Texas is working on this and is trying to provide me with an updated flashloader to try.  Secondly, they also recommend that I try and get the evkmimxrt1020_flexspi_nor_polling_transfer working, as this will provide feedback if there is any hardware issues with my design.  As I mentioned I am having issues with this routine on the RT1021EVK as well and so they provided some additional direction on this.  Once I have more definitive results or info I will post them in this thread.

Thanks again for your assistance!

Cheers,

Sam

[samsaprunoff]

Good day All,

Just a final note about this issue.  Unfortunately I am on a very compressed project schedule and given the issues I have been flash experiencing I decided to abandon the secondary pinmux connection location.  I am certain that the issue would get resolved, but I have run out of time on this (I have been at it for about 3 weeks now) and so I have redesigned my PCB to have the flash connected to the primary pinmux location like used on the RT1021EVK.

Thank you to all that have posted and especially Jeremy, Melissa, Juan, and others at NXP that have been diligently trying to sort out this issue.

Cheers,

Sam

[samsaprunoff]

Good day All,

As a follow up to this... I received my redesigned PCBs (only real change was connecting the serial flash to the primary pinmux location as done on the EVK) this week and subsequently assembled and tested them yesterday.  I am pleased to report that the RT1021 and its flash behave as expected...

Cheers,

Sam

[samsaprunoff]

Good day Jeremy,

Sadly, you did not fully read my response about doing this.  I have done as you suggested (modified the linker to run out of RAM as well as modified the Board_InitPins to reflect the flash connection to the secondary pixmux)  and I am getting the same hard fault (see pictures in my previous post) even if I run the demo program with the original Board_InitPins (linked to run from RAM) on the RT1021EVK ...  As a consequence I conclude that there is a problem with this demo running out of RAM. 

Also, you did not respond to my question if there is an internal register that reflects the currently used/read BootConfig values.  I could only find internal registers that show me the fuse values and the BootMode values, but not BootConfig.  I would like to somehow verify that the BootConfig values are being properly read by the processor even though the respective external pins are measuring the correct state.

Cheers,

Sam

[samsaprunoff]

Good day Jeremy,

Thank you for your response and the linker change modification.  I did modify the Board_InitPin function to reflect the flash connection to the secondary pinmux locaiton.

I modified the linker in the demo program to run out of ram and it does show no flash memory is to be used... which is good.  However, I am unable to run the application, as after download (I am using a NXP LPC-Link2 debugger) I get a Hardfault errors:

I have tried the application on two of my boards and both generate the same error.

Also to rule out an issue with the application I tried to download and run the application on the RT1021EVK and I get the same Bus fault error and so there still must be other changes to the project to run out of RAM.  Please advise.

Thanks in advance!

Cheers,

Sam

[jeremyzhou · Accepted solution]

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