RT1061 can not run the program in spi nor flash but well debug in ram.

[lsjshengll]

I'm a beginner working on driving a LED driver chip via I2C with the RT1061. It runs fine in ram debug mode (LED lights up), but when using flexspi_flash_nor_debug, the hardware initialization fails both in IAR simulation or flashing with jflash. I can read the flash contents, so the code is loaded. I've checked extensively but can't find the cause. Could you please help? Thanks.

I'm using flexspi1, with code partially transplanted from the hello world example. 

[lsjshengll]

I encountered the same issue when using the RT1021 to light up an LED with a regular GPIO. I barely modified the example code, only changing the IO port. I used Keil, and the LED lights up fine in debug mode. However, when using the flexspi_flash_nor_debug, the LED won't light up.

[Gavin_Jia]

Hi @lsjshengll ,

Thanks for your interest in NXP MIMXRT series!

May I ask if you are testing with the example in SDK and RT1060-EVK?

You mean:

- Use examples from SDK;
- The original flexspi_flash_nor_debug can run;
- Flexspi_flash_nor_debug can't run after modifying the IO port?

Is that the case? If there is a problem with my understanding, please help me point it out.

Bests,
Gavin

[lsjshengll]

Hi，@Gavin_Jia 

Thank you for your reply.

- Use examples from SDK;  (see below)
- The original flexspi_flash_nor_debug can run; (Yes)
- Flexspi_flash_nor_debug can't run after modifying the IO port?(I'm not sure)

by the way RT1011 sdk can debug in the nor flash.

I have tried various methods to set up the RT1061 project, including Keil and IAR. Using the MCUXpresso Config tool and doing modification with hello world SDK. All of them have the same issue. The latest Keil project (see attachment) was built with MCUXpress config. ​Only added the I2C chip's driver and the main application. 

This RT1061 board I got from my colleague, it can debug before. I change the flash to W25Q64 and do some test. 

When doing debug in flexspi_nor_flash, it often gets stuck at the following location.

/* invalidate D-Cache */ sets = (uint32_t)(CCSIDR_SETS(ccsidr)); do { ways = (uint32_t)(CCSIDR_WAYS(ccsidr)); do { SCB->DCISW = (((sets << SCB_DCISW_SET_Pos) & SCB_DCISW_SET_Msk) | ((ways << SCB_DCISW_WAY_Pos) & SCB_DCISW_WAY_Msk) ); #if defined ( __CC_ARM ) __schedule_barrier(); #endif } while (ways-- != 0U); } while(sets-- != 0U); __DSB();

[Gavin_Jia]

Hi @lsjshengll ,

Do you mean the issue happened on the board when replaced the flash? Is it possible to debug normally before changing the flash? 

[lsjshengll]

@Gavin_Jia 

I remember there is another difference. I use the flexspi DQS pin(GPIO_SD_B1_05) as I2C_SDA(I didn't connect that pin to flash). I don't know if it will affect Flash.

[Gavin_Jia · Accepted solution]

Hi @lsjshengll ,

That should be the issue. If the external flash does not provide the DQS signal, the DQS pin of the MCU should be floated. It cannot be reused as other functions.

Best regards,
Gavin

[lsjshengll]

@Gavin_Jia 

I have another question: The DQS pin can be routed to two pins (GPIO_SD_B1_05, GPIO_AD_B1_09). Why does using GPIO_SD_B1_05 will affect Flash operation? How does the RT1061 initialization determine this behavior? Do both pins need to be floated? Thank you.

[Gavin_Jia]

Hi @lsjshengll ,

The two optional pins of DQS are not used casually. BootROM supports the FlexSPI primary option and the second option, that is, it has two groups of options. The selection method is the configuration in BootCFG2 or eFuse. The default configuration is the primary option. 

It should be the FlexSPI primary option on your board, so the corresponding DQS can only be GPIO_SD_B1_05.

[lsjshengll]

@Gavin_Jia 

Thank you so much. I will do a test tonight.

[lsjshengll]

@Gavin_Jia 

Yes, but the replaced Flash model is the same. My colleague used this board for some test and the old flash contained his program. So I replaced it with an empty Flash and programmed my own code into it.