TL;DR - We can't seem to download and debug an RT1050 program image to a board that has a QSPI flash attached to the secondary FlexSPI pinmux location.
We've constructed a custom board based on the RT1050 (MIMXRT1052CVJ5B). Because of how many serial I/O ports we had to allocate, we did not use an octal HyperFlash like that on the EVKB; rather, we connected a QSPI flash (S25FL256L) to the secondary pinmux location, as so:
We also replicated the configuration DIP switches that are present on the EVKB. Referring to Table 8-9 of the RT1050 manual, I could see that BOOT_CFG2[2:0] (i.e. BOOT_CFG[10:8]) needed to be "111" for "QSPI device supports 3B read by default (on secondary pinmux option)", not "010" for "HyperFlash 1.8V". So I set the DIP switches to "0000 0011 0110" to select Flash Type 111 and Boot Type 10 (internal boot). And it appears that I've set the DIP switches correctly, because if I reset the processor, I see this on the QSPI pins:
My Logic pod isn't fast enough to capture the actual data that's being transmitted (nor can it decode QSPI), but I can see three bursts... the first two are about 3.7 us each, and the big one is about 259 us long.
The debug pod (SEGGER J-Link Pro) connects OK with the CPU; there was some initial confusion over what debug mode to use, but we now have SWD selected. When I try to program and download an image, the SEGGER four-bar programming window appears, it gets to 25% compare a touch slowly, then 50%, then the window disappears:
Then the debugger lands at address 0x20b4f2 (the actual address for any given run is somewhat random, I got 0x20d136 another time):
And you pretty much can't do anything at this point. The addresses clearly reside inside the ROM region, so presumably the RT1050 was not able to boot successfully and remained in its ROM program.
Here's what I see on my Logic probe while launching the debug session:
That big burst in the middle there is a whole bunch of transfers, each lasting about 259 us and spaced apart every 6-7 ms. So, any ideas what we're doing wrong? I certainly can't rule out a hardware issue, but it looks like the signals between the CPU and the QSPI flash are OK. Maybe one has to do some additional configuration of the J-Link debug launch. Where should I start?