Thanks very much for your reply, I have since learned a few additional things....
I had been using MCUXpresso 10.3 with MIMXRT1064 SDK 2.6.
I also have MCUXpresso 11.1 installed on my PC with MIMXRT1064 SDK 2.7.
In version 2.7 of the SDK, there are two (2) example programs related to SPI Nor Flash. They are:
1.) evkmimxrt1064_flash_component_nor, and
2.) evkmimxrt1064_flexspi_nor_polling_transfer.
This means I have example code for my intended target, and won't be needing to migrate the MIMXRT1050 example code, which, as you know, has a different flash memory map.
The program evkmimxrt1064_flash_component_nor
1) begins with configuring and initializing flash.
2) Then it calls Nor_Flash_Erase_Chip(&norHandle);
3) Then enters a for-loop
for (uint32_t pageIndex = 0; pageIndex < norHandle.bytesInPageSize; pageIndex++)
in which each iteration calls Nor_Flash_Read, Nor_Flash_Page_Program, Nor_Flash_Read (to read back programmed values), Nor_Flash_Erase_Block, Nor_Flash_Read (to verify the previous erasure)
That said, when I try to debug it, if I place a breakpoint at the top of the for-loop, we finally arrive at the breakpoint after a count of 14 seconds. This suggests that flash was perhaps erased.
Upon adding the expression norHandle to my watch window, and expanding the norHandle to view its structure members, all of the structure contents (void *driverBaseAddr, uint32_t bytesInPageSize, uint32_t bytesInSectorSize, uint32_t bytesInMemorySize, and void *deviceSpecific) all show empty Value fields, with the message:
Failed to execute MI command:
-data-evaluate-expression norHandle
Error message from debugger back end:
Cannot access memory at address 0x2000037c
- I pressed Run and received “Break at address “0xdeadbeee” with no debug information available.
- I pressed Run again and got:

- The behavior suggests that the call to Nor_Flash_Erase_Chip stomps on RAM that is used by the debugger. Any thought or suggestions on this are extremely welcome! Cheers,
- Paul