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:
| QSPI | FLEXSPI | GPIO | Ball |
|---|---|---|---|
| CS* | FLEXSPI_A_SS0_B | GPIO_B1_15 | J14 |
| SCLK | FLEXSPI_A_SCLK | GPIO_B1_14 | G12 |
| D3 | FLEXSPI_A_DATA3 | GPIO_B1_10 | L13 |
| D2 | FLEXSPI_A_DATA2 | GPIO_B1_11 | J13 |
| D1 | FLEXSPI_A_DATA1 | GPIO_B1_12 | H12 |
| D0 | FLEXSPI_A_DATA0 | GPIO_B1_13 | H11 |
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?
Hi David Rodgers,
Thanks a lot for your detail information.
In factor, the secondary pin mux option connect to the nor flash, not only related to the BOOT_CFG, BOOT_MODE configuration, you also need to configure the option0 and option1 in the flashloader, that's why you have problems both in the mcuxpresso IDE and MCUBootutility.
About the MCUXpresso IDE associated with JLINK, it may need to modify some files in the JLINK driver. Actually, if you are using the IAR, it will be more easy to modify it, you can modify the .board files.
But, about the MCUBootUtility tools, I have checked it with the tool author yesterday, but forget to tell you the details, now, please use the MCUbootUtility to download the code again.
1. RT board enter the serial download mode, BOOT_MODE=01.
2. Open the MCUBootUtility tool, configure the following point:
option 0[Has option1]=1, option1[enable second pinmux] =1, just choose the secondary pin mux.
Then, when you download the code, the flashloader will try the nor flash which is connect to the secorday mux pins.
Please try it on your side.
Any updated information, please kindly let me know.
Have a great day,
Kerry
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi jayheng,
It appears I've achieved some level of success with the MCU Boot Utility. I don't have a working target yet, but it appears that the utility is now doing what it's supposed to be doing. After some investigation, I determined that I needed to make one more setting change for my Cypress S25FL256 device, to select "Set StatusReg2[1]" for Quad Mode:
I did also add a post-build step to generate an SREC file instead, and that seemed to make the tool much happier. It passed the phase of generating the bootable file (in the log, the tool says "Origianl image file is a bootable image file"), then spent almost two minutes sending the image to the target. The utility finished with a stopped clock looking like this:
And now when I do an internal boot, I see a much different pattern on the logic analyzer:
This is strongly suggesting to me that I have in fact programmed the flash on my board. So now I need to turn my attention to getting the debugger to push a useful image into my target hardware.
David R.
Hi Austin Wilhite,
Please check my attached JLinkDevices.xml, it modify the RT105X from hyper flash to QSPI flash.
Wish it helps you!
Have a great day,
Kerry
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
