How to boot i.MX RT1062 from LPSPI3?

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

How to boot i.MX RT1062 from LPSPI3?

2,305 Views
andyturk
Contributor I

I'm working on a custom board with a i.MX RT1062 processor and NOR
flash connected to LPSPI3.  I need to be able to boot this board from
NOR flash. Section of the reference manual 8.6.8 says this is supported

by the ROM.

However, even after burning the LPSPI_PORT_SEL fuses (0x6D0[26:25]) as
0b10, there's no activity on the LPSPI3 signals after a power on
reset. E.g., PCS0 and SCK remain at 0V and never change while the ROM
code is running.  I've also burned BT_FUSE_SEL (0x460[4]) with no
effect.

Examining SW_MUX_CTL for GPIO_AD_B0_00 in a debugger just after POR,
shows that pin (and the others for LPSPI3) is configured for
MUX_MODE=ALT5 (i.e., regular GPIO). If the ROM tried to use LPSPI3,
I'd expect these pins to be configured as ALT7.

The NOR flash works just fine when we load the application directly
into OCRAM with a debugger.

The reference manual is not particularly clear on the configuration
for booting from LPSPI.  Table 8-10 says that BOOT_CFG[7:4] = 0b0000
is supposed to mean "Serial NOR device selected as boot
device". However, Table 8-9 specifically lists FlexSPI (not LPSPI) as
the interface for 0b0000.

So my question is, what specifically needs to happen in order for the
ROM to load the first 4k of data from LPSPI3 after a power on reset?

Labels (1)
0 Kudos
14 Replies

1,908 Views
andyturk
Contributor I

jeremyzhou‌ and jayheng‌,

Table 8-36 of the reference manual (Rev. 1, 12/2018) has incorrect information about the location of the EEPROM recovery enable fuse. It lists the location as 0x4D0[24], which is wrong.

Screen Shot 2019-08-16 at 2.39.22 PM.png

The actual location is 0x6D0[24]. When I burned the fuse at 0x6D0[24], the boot ROM correctly configured LPSPI3 and loaded a block of data after POR.

Table 21-9 on page 1375 shows the correct location.

Screen Shot 2019-08-16 at 2.43.07 PM.png

:facepalm

0 Kudos

1,908 Views
jay_heng
NXP Employee
NXP Employee

I am sorry about the document issue, I will inform doc team of this issue.

Btw, if you try my tool MCUBootUtility, you may discover this issue earlier, my tool will help burn those fuses correctly.

0 Kudos

1,908 Views
andyturk
Contributor I

jayheng

Our application is linked to run directly from OCRAM. The vector table begins at 0x20200000. I would like to be able to put a copy of the application image in NOR flash and have the boot ROM copy it to the beginning of OCRAM and begin execution there after POR.

Our linker file puts the IVT structure at 0x20200400, so when the boot ROM reads the initial 4kb of the application image from LPSPI3, it will find the IVT at offset 0x400. Here's what the IVT looks like inside the running application:

Screen Shot 2019-08-21 at 9.30.47 AM.png

When the board boots, I can see the boot ROM loading a lot of data, but when I'm able to break in and look at the contents of OCRAM, I never find the IVT at 0x20200400.

How can I get the boot ROM to copy our application image from LPSPI3 to OCRAM at 0x20200000 and begin execution with the reset vector at 0x20200004?

0 Kudos

1,908 Views
jeremyzhou
NXP Employee
NXP Employee

Hi andy turk,

Thanks for your reply.
Please refer to the application note to generate a boot image to enable non-XIP boot for Serial NOR/EEPROM, the generating process is similar as for the SD Card.
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,908 Views
andyturk
Contributor I

jayhengjeremyzhou

Any suggestions?

0 Kudos

1,908 Views
andyturk
Contributor I

jeremyzhou

You asked about how we "program the image to the chip". I'm not sure whether you're asking about the contents of our SPI flash, the executable image for the i.MX, or how we burned the fuses. I'll cover all the bases to make sure...

1. The NOR flash is not involved in the boot process right now and doesn't contain any executable code for the i.MX. Eventually (once we figure out this LPSPI3 problem), we will put an executable image there. Our application contains code to read and write the NOR flash. The flash chip functions as expected when everything is configured by our application, so the boot ROM should be able to use it too.

2. We currently download the executable image into OCRAM via a Segger J-Link.

3. Our application contains code to burn fuses. A command interpreter accepts a command like "fuse write 0x8f0 0x00000001", and I used that to configure the fuses for the board I'm debugging with. You may have noticed an "extra" bit was blown in 0x4d0. I accidentally blew 0x8000, so that location contains 0x01008000. Could the extra bit be causing a problem?

Here's the relevant portion of our schematic. The LPSPI3 signals are on the upper left of U1E and connect to U6 near the bottom.

lpspi3.png

jayheng

MCUBootUtility looks very impressive. However, I don't use Windows or Python for development, so I hope it won't be necessary to set up (another) machine just for that.

You mentioned "LPSPI pinmux" a couple of times. Do you mean to verify that we've electrically connected the NOR flash correctly? I think we have, since the flash operates normally under our application.

The "Chip-specific Boot Information" in the reference manual lists LPSPI3 as a supported boot peripheral with the GPIO we're using in ALT7 mode. Whenever I break in to look at the registers while the boot ROM is active, GPIO_AD_B0_00 through GPIO_AD_B0_03 are all at ALT5.

0 Kudos

1,908 Views
jay_heng
NXP Employee
NXP Employee

What's your boot mode setting? Is this NOR Flash (U6) the only boot device in your system?

If GPIO_AD_B0_00 - GPIO_AD_B0_03 pins weren't in ALT7 mode during ROM boot, that means ROM didn't try to boot LPSPI NOR Flash at all.

0 Kudos

1,908 Views
andyturk
Contributor I

jayheng

The boot mode setting is 0b00 (shown in an earlier screen grab from the debugger).

Yes, the NOR flash on LPSPI3 is the only non-volatile memory we have on this board.

0 Kudos

1,908 Views
jeremyzhou
NXP Employee
NXP Employee

Hi andy turk,

Thanks for your reply.

1) Could the extra bit be causing a problem?

-- Maybe, as the arrange of value is reserved, and it's highly recommended to not program the reserved bits.

2) According to your clarification, you debug the demo project into OCRAM currently, so I'm curious that how you get the conclusion that the image can't boot from the LPSPI3.
In term of the schematic, you should add a pull-up resistor to the HOLD and WP pins.

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,908 Views
andyturk
Contributor I

jeremyzhou

My current issue isn't a problem with the contents of firmware image, it's that the boot ROM never attempts to load anything at all from LPSPI3. What I expect is that the boot ROM should configure the GPIO_AD_B0_0x pins and load the first block of data from flash after a power on reset. What I observe is that nothing happens at all on these pins after POR... no chip select, no clock, etc. Whenever I break in with a debugger (before our application has been loaded), those GPIO are configured as ALT5 rather than the required ALT7.

0 Kudos

1,908 Views
jay_heng
NXP Employee
NXP Employee

BOOT_CFG[7:4] determines primiary boot device type, if ROM cannot boot from selected primiary boot device, then ROM will try to boot from recovery boot device (Serial NOR/EEPROM) connected to LPSPIx.

Please check LPSPIx pinmux in System Boot chatper, and you can try this GUI tool to program recovery boot device. if you can program recovery boot device by this GUI tool, that means LPSPI pinmux is correct.

0 Kudos

1,908 Views
jeremyzhou
NXP Employee
NXP Employee

Hi andy turk,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
The Figure 8-1 illustrates the boot flow of the i.MX RT1062 and we can summary some principles according to it.

pastedImage_1.png
1. The Serial EEPROM/NOR mode is a backup mode if the primary boot (likes Table8-9 shows )device fails, the boot ROM tries to boot from the recovery device, such as EEPROM and serial flash, using one of the LPSPI ports.

pastedImage_2.png
3. To enable the recovery device, the EEPROM_RECOVERY_EN fuse must be set, Additionally, the serial EEPROM fuses must be set as described in Table8-36.

pastedImage_3.png

Hope this is clear.

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,908 Views
andyturk
Contributor I

Jeremy,

This board has BT_FUSE_SEL set to '1', EEPROM_RECOVERY_EN set to '1', LPSPI_PORT_SEL set to '10'. However, there's no activity on GPIO_AD_B0_00..GPIO_AD_B0_03 after a power on reset. I.e., the boot ROM never attempts to load anything over LPSPI3.

Questions:

1. Is it necessary to blow additional fuses to support booting from LPSPI3?

2. Is it possible that the boot ROM is "stuck" somewhere before attempting a recovery boot from LPSPI3?

3. Can I look in memory somewhere to see what the boot rom thinks it's doing?

Here are some screen grabs from my debugger showing the OCOTP shadow registers. These captures were taken after applying power to the board and before loading our application into OCRAM. At this point, the only code to execute is the boot ROM. Yellow highlights show the fuses that have been burned to allow booting from LPSPI3:

Screen Shot 2019-08-07 at 7.31.32 AM.png

This capture shows the SRC.SBMRx registers, also captured while the boot ROM has control:

Screen Shot 2019-08-07 at 7.44.34 AM.png

0 Kudos

1,908 Views
jeremyzhou
NXP Employee
NXP Employee

Hi andy turk,

Thanks for your reply.
1. Is it necessary to blow additional fuses to support booting from LPSPI3?
-- For your case, it's not necessary to configure other fuse bits at all.
2. Can I look in memory somewhere to see what the boot ROM thinks it's doing?
-- No, I'm afraid it's unavailable to make it.
I was wondering if you can share the schematic of the chip connecting the i.MX RT1062 via LPSPI3 port. In addition, whether you can introduce the steps of you did to program the image to the chip.
I think these informations can help me to figure the issue out.


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