AnsweredAssumed Answered

RT1050 - Debugging with QSPI flash on secondary pinmux

Question asked by David Rodgers on Jul 31, 2019
Latest reply on Aug 23, 2019 by Austin Wilhite

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:

Logic capture of RT1050 trying to boot from QSPI flash


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:

SEGGER flash download


Then the debugger lands at address 0x20b4f2 (the actual address for any given run is somewhat random, I got 0x20d136 another time):

Debugger at address 0x20b4f2

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:

Logic capture of starting RT1050 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?