We are developing a custom board based on IMXRT1021 with QSPI flash (same IS25LP064A-JBLE on EVK). I could get the board up and running evkmimxrt1020_igpio_led_output without any issue using JLink debugger. It wrote to the flash address space successfully when uploading the binary through JLInk. Not that I modified the example code to burn the fuses BT_FUSE_SEL and FORCE_INTERNAL_BOOT bits and all other bits in BOOT_CFG1 and BOOT_CFG2 to 0.
However, when the debugger is disconnected and power recycling to the board did not run the expected LED blinker. Then I started a debugging session via MCUExpresso + JLink, halt the program then do a 'Restart' through debug toolbar. That causes the processor to reset, and attached to the process without loading the binary again, and it was found processor crashes to unknown address when executing IOMUXC_SetPinMux() inside BOARD_InitPins() example function. If I have an infinite loop before BOARD_InitPins() after RESET example works fine up to the loop. I am just thinking this is due to some security features which not allowed to alter IO pins.
I ran the same software on IMXRT1021EVK and it worked fine, even after POR. BOOT_CFG[1] and BOOT_CFG[2] configurations are same on EVK and our custom board. Having the same QSPI flash part and same interface, it makes sense to have the same configuration there too. But I really don't understand why it fails at IOMUXC_SetPinMux. Anybody has any thoughts on this. Much appreciated.
Update 1:
I realized the particular GPIO was different on the EVK and the custom board. Having set the same GPIO (IOMUXC_SetPinMux(IOMUXC_GPIO_SD_B1_05_GPIO3_IO25, 0) )on the EVK causes the EVK too to crash similar to the custom board. Interestingly IOMUXC_SetPinMux(IOMUXC_GPIO_SD_B1_04_GPIO3_IO24, 0) works fine on both boards. And IOMUXC_SetPinMux(IOMUXC_GPIO_SD_B1_05_GPIO3_IO25, 0) seems to be either SDK or processor-specific issue. Can anyone from NXP answer this? It is reproducible on IMXRT1020 EVK? Thanks,
Update 2:
Just found IOMUXC_GPIO_SD_B1_05_GPIO3_IO25 has an alternative use for FLEXSPI_A_DQS which is not actually connected to QSPI Flash, but changing that causes the flash to error. Probably NXP should highlight this in the datasheet and reference manuals, so this pin can be avoided.
