RT1176 bootROM Boot Device Init Fail

[jk_rsc]

Hi,

We are currently working on a custom board with a i.MXRT1176 booting from a QSPI NOR flash connected to FlexSPI1. The connnections are the same as the eval kit (SD_B2_06 - SD_B2_11). Boot Mode and Boot Config are GPIO controlled with pull resistors to the correct config (same as EVK). 

Our firmware is booting correctly on the EVK but not on our custom board.

Using the "NXP MCU Boot Utility" to check the boot log for both our custom board and the EVK we see the following logs:

0x0001f000: Startup Init Pass
0x0201f000: ROM Patch Init Pass
0x0101f000: Hardware Init Init Pass
0x0501f001: Master Boot Init Pass
data[0] = 0x0000000c
0x0901f303: Boot Device Init Fail
data[0] = 0x00000004, boot type -> Manufacture Boot
data[1] = 0x00000000, boot periph -> Manufacture - SDMMC
data[2] = 0x00000001, periph instance -> 1
0x0901f003: Boot Device Init Pass
data[0] = 0x00000008, boot type -> Serial Boot
data[1] = 0x00000011, boot periph -> Serial - UART/USB HID
data[2] = 0x00000000, periph instance -> 0
0x0902f001: Boot Device Call Pass
[...]

The EVK shows correctly booting from FLEXSPI NOR with this section as the relevant difference:

0x0501f001: Master Boot Init Pass
data[0] = 0x0000000d
0x0901f003: Boot Device Init Pass
data[0] = 0x00000001, boot type -> Primary Boot
data[1] = 0x00000005, boot periph -> Primary - FLEXSPI NOR
data[2] = 0x00000000, periph instance -> 0
0x0902f001: Boot Device Call Pass
[...]

How should we interpret these logs?
The chip tries to boot from SDMMC. Is this caused by an error and the bootROM chooses "Manufacture Boot"? Or is our custom board misconfigured for SDMMC boot?

Some other things we verified:
- The connected qspi flash is working correctly. XIP works when flashing and starting the firmware with a debugger
- When coming out of reset the rt1176 does not drive any flexSPI1 pins. SS0 stays unchanged until flashing through a debugger. (compared to the EVK with an empty flash still reads the boot header region)
- Boot mode and config are the same on the custom board and the EVK:

Custom board:

J-Link>mem 40C04008 8
40C04008 = 00 00 00 00 09 00 00 00

EVK:

J-Link>mem 40C04008 8
40C04008 = 00 00 00 00 09 00 00 02

Any help/pointers are appreciated

[diego_charles]

Hi @jk_rsc 

Thank you for reaching out! 

I appreciate that you checked already the SBMR1 (0x40C04008) I wonder regarding the contents  of the SBMR2 . Could you let me know about them?

I understand that you are using  boot config pins  to override for the BOOT_CFG1 fuses. You have not burned other fuse on the chip already, correct?

We could also consider if on your custom board the  boot config pins  are shared and used to drive other signals on your custom board. Is this the case? Would you be able to share an schematic portion corresponding to this?

Let me know if there is any other detail we could be missing. 

Thank you!

Diego

[jk_rsc]

Hi @diego_charles,

Thanks for the quick response.

The contents of SBMR2 are:

J-Link>mem 40C0400C 4
40C0400C = 09 00 00 00

We have not changed any fuses on the custom board.
Here is a screenshot of the fusemap scanned with the NXP MCU Boot Utility:

Here are the relevant boot-mode pins in the schematic:

And the boot-config pins:

They are not used for any other signals.

[diego_charles]

Hi @jk_rsc 

Thank you for your reply! I have been checking your redouts from your custom board.

For SBMR1 40C04008 =  09 00 00 00 you have some reserved bits of  BOOT_CF4  turned on.

For SBMR2 40C0400C = 09 00 00 00, my interpretation is that  you are getting boot mode (BMOD) set to serial downloader mode 0b01 and reserved bit 27 on.

If you program a image on your custom board,  and the boot with  boot mode pins to internal boot (0b10)  are you still getting BMOD bitfield set  serial downloaded mode (0b01)? . If yes, this can be seen as if the bootROM kept executing and  the XIP image was never attempted to boot, or is not valid/corrupted.

I wonder if there is any diffence on the code your are running on the EVK and the code on the custom board, also if you are using the same flash model than the one implmented in the EVK . Could you explain? 

Best regards, 

Diego

[jk_rsc]

Hi @diego_charles 

The Firmware, Flash, boot config and Fuses are the same as the EVK.
SBMR1 and SBMR2 are the same on EVK and our custom board, except SBMR2[1] which is 1 on EVK and 0 on the custom board. (SBMR1: 0x00000000, SBMR2: 0x0900000X)

I have been probing the Chip Select of the Flash to see if there is any activity during the boot. On our custom board the Chip Select pin does not change during Boot. I believe the bootROM never even tries to communicate with the Flash.

I believe what is happening is this path in the boot flow:

Which means internal primary boot fails.
Since there is never any activity on the qspi traces the fault seems to happen before or during initialization of the FlexSPI1 peripheral.

How can I debug the logic of the BootROM?
Are there any sources available I can look at?
Or are there any more detailed flowcharts where I could find information on what path the BootROM is taking?

Looking at the Boot log from MCU Boot Utility the first difference happens right after "Master Boot Init Pass":

Custom Board:

0x0501f001: Master Boot Init Pass
data[0] = 0x0000000c

EVK:

0x0501f001: Master Boot Init Pass
data[0] = 0x0000000d

Is there any resource I can check to see what these data values mean?

Thanks for your help

[diego_charles]

Hi @jk_rsc 

Thank you for your reply.

I want to maintain you updated, at  this moment I do not have more information to analize the log that you are seeing, but I am working on this, allow me to get back to you. 

Just to be sure, you are able to write the image on to the custom board flash successfully all the time, correct?

Secondly,  could you dump the flash contents and verify that they match the image binary?

Diego

[jk_rsc]

Hi @diego_charles 

Thanks for the update.
Yes, we are able to read and write to the flash correctly via the debugger and also via the serial boot using the NXP MCU Boot utility (in the Boot Device Memory tab). Comparing the dumped flash to the firmware matches.

As mentioned, I see no activity on the SPI traces during normal boot. I suspect something is triggering the BootROM to choose "manufacture mode" before the flash is accessed, either an error or misconfiguration.

A different possibility is that BOOT_MODE is 0 or 1 instead of 2 to begin with. the SBMR registers, the pin configuration and the fuses suggest otherweise, but maybe they are shadowed by some mechanism we do not consider?. Is there a way to verify what BOOT_MODE value the BootROM acts on?

Let us know if we can do any more tests with our hardware, and thanks for keeping us updated.

[diego_charles]

Hi @jk_rsc 

I am very sorry for the delayed response! 

I have been trying to replicate your problem with our EVKB and consulting internally for feedback. 

The problem lies on data[0] = 0x0000000c, and not  0x0000000d

According to our team, below three settings are valid to make sure that data[0] begins with  0xd

1. SRC->SBMR2[25:24] = 2'b00,  SRC->SBMR2[4]=1

2. SRC->SBMR2[25:24] = 2'b10

3. SRC->SBMR2[25:24] = 2'b11, Fuse 0x960[3] = 1

Let me provide more some details about a testing I did.

   I tweaked the application's image LUT (bad lut that does not allow image to boot ) from the led_blinky SDK example to make it fail and changed the boot config pin settings to a random value. The bootROM log reveals that data[0] ends always with 0x0000000d

 On my test The bootROM will also check for manufacure boot, but failing too. 

   Test 1 bad LUT, ramdom SW2 boot config to:  0b01000_00000

A first failed attempt was made to boot from FlexSPI NOR too 

Test 2   Test 1 bad LUT, ramdom SW2 boot config to:  0b00111_11110

Several first attempts where made to boot from flexspi nand.

Your log from the failed board. 

       I can also see that BootROM only attempts to boot from Manufacture boot and data[0] end with ends  0x0000000c. I could not replicate this situation.

Then, while my  MCU was still into serial downlaoder, I attached to the SWD and manually read the SMBR2, I was able to get the following readout: SBMR2 = 0x0200_0009

Best regards, 

Diego