i.MXRT117F - unable to run program from flash, debugger stuck at addresses 0x2015f2 and 0x223104

[transistor32]

I'm having trouble getting a program to run on a custom board based around the MIMXRT117FCVM8A. Please could someone help?

I'm trying to run the evkmimxrt1170_igpio_led_output_cm7 and snl_vizn3d_iot_iled_blinky_cm7 projects with limited success. Both these projects have been modified to use the GPIO assignment used for the LED on my board, but are otherwise original. I have tried modifying the RAM entries in the memory configuration but I haven't been able to run the code from Flash. The evkmimxrt1170_igpio_led_output_cm7 project works if I remove the flash entry from the memory map, and in this case the program runs from SRAM.

I've seen some previous posts which suggested that the addresses 0x2015f2 and 0x223104 are purely a debugger issue, and that the code would run from flash without a debugger, but in my case it doesn't run from flash without the debugger either.

Some information about my hardware:

Flash: IS25LP128-JBLE

SDRAM: W9825G6KH

Oscillators: 24MHz crystal, 32.768kHz crystal

I am using a JTAG connection and have an NXP MCULink and a Segger J-Link; the problem is the same with both.

I don't currently have an i.MXRT1170 dev board so I'm not able to try running the exact same project on the dev board, as I have an i.MXRT1160 dev board.

Flash is connected as follows:

Flash CLK - FlexSPI_A_CLK	G14
Flash CS - FlexSPI_A_SS0	F17
Flash IO0 - FlexSPI_A_D0	F15
Flash IO1 - FlexSPI_A_D1	H15
Flash IO2 - FlexSPI_A_D2	H14
Flash IO3 - FlexSPI_A_D3	F16

The BT_CFG pins are needed for other functions, so I am using Boot from Fuses by setting the BOOT_MODE pins to 00. I've used a DIP switch on the BOOT_MODE pins so that I can also access the Serial Downloader (USB). I've used NXP MCU Boot Utility to set fuse 0x960[4] (BT_FUSE_SEL) to 1 and I've left all other fuses in their default state. I believe this should be the correct configuration to boot from an external QSPI Flash on FLEXSPIA, and activity is seen on the Flash pins when resetting the board.

The various configuration pins are connected as shown in the table below on my board. I wouldn't expect the BOOT_CFG pins to matter if I'm using boot from fuses, but I've included them in the table below for reference.

Function	My board
U10 - ONOFF	10k to VDD_SNVS_ANA
T8 - WAKEUP	10k to VDD_SNVS_ANA
T10 - POR	Active low reset
T9 - PMIC_STBY_REQ	Floating
U9 - PMIC_ON_REQ	10k to VDD_SNVS_ANA
T11 - TEST_MODE	GND
T7, P6 - BOOT_MODE	00 (boot from fuses) (connected to DIP switch)
C9 - BOOT_CFG[11]	Floating
C7 - BOOT_CFG[10]	Floating
D7 - BOOT_CFG[9]	Pulled down
E9 - BOOT_CFG[8]	Pulled down
F8 - BOOT_CFG[7]	Pulled up
E8 - BOOT_CFG[6]	Pulled up
A14 - BOOT_CFG[5]	Pulled up
B14 - BOOT_CFG[4]	Pulled up
C13 - BOOT_CFG[3]	Pulled up
A15 - BOOT_CFG[2]	Pulled up
E12 - BOOT_CFG[1]	Floating
D10 - BOOT_CFG[0]	Floating

Power rails are as below:

Pin	My board
R12 - VDD_LPSR_IN	3V3
J13 - VDDA_ADC_3P3	3V3
G16 - ADC_VREFH	1V8
K15 - VDDA_ADC_1P8	1V8
M11 - VDDA_1P8_IN	1V8
M5, N5, L5 - DCDC_IN	3V3
M7, M8, M6 - DCDC_ANA (out)	1V8
K8, K9, L8, L7 - DCDC_DIG (out)	VDD_SOC (1V)
H8, H9, H10, J8, J9, J10, K10 - VDD_SOC_IN	VDD_SOC (1V)
F7, F6, G6 - NVCC_EMC1	3V3
H6, J6 - NVCC_EMC2	3V3
P7 - NVCC_LPSR	3V3
M12 - NVCC_GPIO	3V3
D12 - NVCC_DISP1	3V3
E7 - NVCC_DISP2	3V3
D14 - NVCC_SD1	3V3
G13 - NVCC_SD2	3V3
F9 - VDD_MIPI_1P8	1V8
F10 - VDD_MIPI_1P0	1V (from VDD_SOC)
U12 - VDD_SNVS_IN	3V3
U11 - NVCC_SNVS	VDD_SNVS_ANA
H12 - VDD_USB_1P8	1V8
G12 - VDD_USB_3P3	3V3

The Flash appears to be getting programmed with data after trying to run a debug session. I can read it back with NXP MCU Boot Utility and see what looks like all the expected blocks of data:

1. 0x30000400 - starts "FCFB", FlexSPI Configuration Blocks
2. 0x30001000 to 0x3000102B - starts with 0xD1 as the first byte, IVT header
3. 0x30002000 to 0x300090f0 - the start of this section looks like an ARM startup file
4. 0x30010000 to 0x30082490 - looks like program code

Attached is the current memory map that I'm using and all the fuse values.

[transistor32]

After continuing to work on the problem a bit longer, I have found the solution.

snl_vizn3d_iot_iled_blinky_cm7 didn't work from either flash or RAM because I hadn't updated all the pin definitions correctly. The program did run, the problem was only the GPIO assignment, so it didn't appear to do anything.

For evkmimxrt1170_igpio_led_output_cm, I started again from scratch with a fresh SDK example (evkmimxrt1170_lvgl_demo_widgets_cm7) and found that it worked both from Flash and RAM too. I rebuilt and debugged the project after every small change to find out what broke the project. The project stopped working from Flash when I used the SDK manager to add some libraries (specifically PWM and XBARA, but that might not be significant).

The SDK manager changed some defines in the .cproject file. In particular:

Changed XIP_BOOT_HEADER_DCD_ENABLE=1 to XIP_BOOT_HEADER_DCD_ENABLE=0
Changed LV_CONF_INCLUDE_SIMPLE=1 to LV_CONF_INCLUDE_SIMPLE
Added XIP_BOOT_HEADER_XMCD_ENABLE=1

Reverting these defines back to their original values made the project work from Flash, so it looks like there is a problem with the SDK manager.

I also note that the SDK manager adds some duplicates to the file path lists in the .cproject file, which prevents the project from building due to linker errors until the duplicates are removed. I'm not sure what I'm doing wrong, is the SDK manager broken for everyone? I'm using MCUXpresso IDE v11.6.0 [Build 8187] [2022-07-13].

[PabloAvalos]

Dear @transistor32 

Thanks a lot for reaching our technical support. I really appreciate you were so patient.

It is good to us to know that you could solved the issue by updating pin definition and starting SDK example again.

Regarding the issue with the SDK manager, I think it is a bug on that one. I will let my development team know to fix it for next release of MCUXpresso version and SDK version. Also, note that MCUXpresso v11.6.1 is now available, please try to run your project on this one to see if the issue persists.

Thanks a lot for your time and explanation on how you solved the problem. It is pretty useful to whom it has the same issue. Please let me know if you have any additional comment or concern I can help you with.

Best Regards.
Pablo Avalos.