AnsweredAssumed Answered

RT1050 - Debugging with QSPI flash on secondary pinmux

Question asked by David Rodgers on Jul 31, 2019
Latest reply on Aug 15, 2019 by Jay Heng

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:

QSPIFLEXSPIGPIOBall
CS*FLEXSPI_A_SS0_BGPIO_B1_15J14
SCLKFLEXSPI_A_SCLKGPIO_B1_14G12
D3FLEXSPI_A_DATA3GPIO_B1_10L13
D2FLEXSPI_A_DATA2GPIO_B1_11J13
D1FLEXSPI_A_DATA1GPIO_B1_12H12
D0FLEXSPI_A_DATA0GPIO_B1_13H11

 

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?

Outcomes