topic Re: RT1050 - Debugging with QSPI flash on secondary pinmux in i.MX RT Crossover MCUs

RT1050 - Debugging with QSPI flash on secondary pinmux

dmarks_ls — Wed, 31 Jul 2019 23:27:04 GMT

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?

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

kerryzhou — Fri, 02 Aug 2019 09:57:26 GMT

Hi David Rodgers ,

What's the IDE you are using?

If you want to debug the code in XIP mode, it also related to the flashloader which associated with the IDE.

So, in my opinion, I suggest you use the tool download the code to your external memory at first, instead of debug it, but you need to enter the serial download mode.

You can try the MCUBootUtility tool, which can be downloaded from this link:

https://github.com/JayHeng/NXP-MCUBootUtility/releases/tag/v2.0.0

The user manual link:

GitHub - JayHeng/NXP-MCUBootUtility: A one-stop boot utility tool based on Python2.7+wxPython4.0, it can help you get st…

After you download the code, you can enter the internal boot mode again, check the code function.

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.
-------------------------------------------------------------------------------

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

dmarks_ls — Fri, 02 Aug 2019 13:32:41 GMT

I'm using MCUX v11.0.0. I'll try the serial download tool on Monday, but I hope I'm going to be able to load firmware into our board using a debug pod at some point. Is it necessary to load firmware into a blank board using serial download before the board will accept a firmware image via debug pod w/ internal boot?

David

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

dmarks_ls — Mon, 05 Aug 2019 18:15:56 GMT

So, I'm trying to use the MCU Boot Utility, with limited success. I changed BOOT_MODE to 01 using the DIP switches, plugged our board into my PC using a USB cable, pressed reset, and saw the USB HID device appear in Device Manager; I also saw the VID/PID 0x1FC9/0x0130 appear in the "Port Setup" drop-down boxes. I ensured i.MXRT105x was selected, then opened Boot Device Configuration and switched the device model to ISSI IS25xx. I clicked Connect to ROM and saw the "light" go yellow, then green, then blue, showing a VID/PID of 0x15A2/0x0073. So we've got a valid connection to the target. (If I forget to change the boot device from HyperFlash to QSPI flash, I get a special message about that.)

However, the "All-in-One Action" button isn't working. I select my application image file (AXF) from my project, then explicity select ".out(acf) from MCUXpresso" as the image type. I have "DEV Unsigned Image Boot" selected. I click the AIO Action button, the UI grinds for about 8-9 seconds, then I get this dialog pop-up:

My copy of the Boot Utility is located in "C:\NXP\NXP-MCUBootUtility-2.0.0\bin", so there's no spaces in the install path (can't believe we're still dealing with this in 2019). So, what exactly am I supposed to do now?

(Also, the user guide on GitHub has a broken image. In the section "3.3.1 Mode 1: No security measures are enabled", the diagram only includes the top 5-10% of the image; the rest is blank. And I'd really like to see that particular diagram, since this is the section I'm having trouble with.)

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

dmarples — Mon, 05 Aug 2019 21:59:50 GMT

I suspect the internal pullups are not switched on when using the secondary pinmux option, with the result that the flash is write protected at boot. My configuration now has 100K to 3v3 on /CS, DI and /HOLD, and then everything is peachy for me.

Good luck!

DAVE

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

kerryzhou — Tue, 06 Aug 2019 02:41:02 GMT

Hi Dave Marples,

Thanks a lot for your updated information.

The MCU internal pull up is weak, so normally, in the practical usage, it's better to add the external pull up.

So you still have any further question.

If you still need help from my side, 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!

Like • Show 0 Likes0 Reply

Actions

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

dmarks_ls — Wed, 07 Aug 2019 20:32:45 GMT

kerryzhou‌ -- I think there was some confusion, Dave Marples offered his own insight on my original question; that was not me replying to my own thread. In my hardware design, I already have a 10K pullup on CS* and 33K pullups on DQ3/HOLD* and DQ2/W*, matching the implementation on the EVKB. Are you recommending any additional pullups?

David R.

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

kerryzhou — Thu, 08 Aug 2019 05:50:44 GMT

Hi David Rodgers,

So sorry, Dave's reply really confuse me, which let me think it also from your reply. I mix it together, it's my fault.

So, your problem still in the connection with MCUbootutility right?

Could you share some screenshot about the connection problem on yourside?

Do you also configure the Boot Device as FLEXSPI NOR, and configure the Boot Device configuration as your own QSPI?

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

dmarks_ls — Thu, 08 Aug 2019 16:13:56 GMT

kerryzhou‌,

I've provided several screenshots above, showing QSPI bus activity, the behavior of the SEGGER programming window, the debugger context when the debug session launches, and the error dialog when I try programming the board directly using MCU Boot Utility.

I'll provide a summary of my configuration and my issues here:

We have a custom RT1052 board with a QSPI flash attached to the secondary pinmux location, as specified above. The flash was not pre-programmed prior to board assembly; it should be completely blank.
The board has a full complement of DIP switches matching the EVKB, allowing configuration of all relevant BOOT_CFG and BOOT_MODE settings.
We appear to have the correct BOOT_CFG/BOOT_MODE selection (internal boot, QSPI on secondary pinmux) because the RT1052 accesses the QSPI flash after reset.
The MCUXpresso debug launch is not programming the board as it should; the SEGGER window tries comparing flash, gives up at 50%, and then pauses and drops somewhere into the ROM code.
If I configure the RT1052 for "Serial Downloader" instead of "Internal Boot", I can connect the MCU Boot Utility using the USB connection on our board.
The MCU Boot Utility cannot seem to build and/or download a boot image to the RT1052; please see my August 5 reply above.
It is unclear to me whether it should be possible to perform an internal boot / SWD code download to a board with blank flash, or whether is necessary to have some load of code in the flash before a SWD debug launch and code download will work.

Can you provide any assistance for these issues?

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

dmarples — Fri, 09 Aug 2019 00:26:21 GMT

David,

Sorry if I confused matters, was trying to help. I went through a _lot_ of pain getting this configuration running, so I'd like to help a fellow sufferer

JLink certainly can program a blank flash on the secondary pinmux, that is (now!) what I do all of the time. I'm on 1021, but I can't imagine there are differences. Given that your CPU is trying to access the flash I would be inclined to suspect you've got the various initialisation tables a bit wrong (or, more probably, MCUX has, since I don't think you generate them manually in a MCUX configuration).

I'm running NuttX and the start of my flash looks like this;

60000000 A __boot_hdr_start__
60000000 R flash_config
60001000 A __boot_hdr_conf__
60001000 R g_image_vector_table
60001020 R g_boot_data
60001030 A __boot_hdr_end__
60002000 A _stext
60002000 T _vectors

...and the various data in each of those tables is as follows;

000000 4346 4246 0400 5601 0000 0000 0300 0003
000010 0001 0000 0401 0000 0040 0000 0000 0000
000020 0000 0000 0000 0000 0000 0000 0000 0000
<SNIP>
001000 00d1 4120 2000 6000 0000 0000 0000 0000
001010 1020 6000 1000 6000 0000 0000 0000 0000
001020 0000 6000 ffff 1f7f 0000 0000 ffff ffff
001030 ffff ffff ffff ffff ffff ffff ffff ffff

The source that I build those tables from is;

__attribute__((section(".boot_hdr.conf")))
const struct flexspi_nor_config_s flash_config =
{
  .mem_config =
  {
    .tag                    = FLEXSPI_CFG_BLK_TAG,
    .version                = FLEXSPI_CFG_BLK_VERSION,
    .read_sample_clksrc     = FLASH_READ_SAMPLE_CLK_LOOPBACK_INTERNELLY,
    .cs_hold_time           = 3u,
    .cs_setup_time          = 3u,
    .device_mode_cfg_enable = true,    
    .device_mode_seq.seq_num= 1,
    .device_mode_seq.seq_id = 4,     /* These commands set the Quad bit */ 
    .device_mode_arg        = 0x40,  /* on the flash to drive 4 pins.   */
    .device_type            = FLEXSPI_DEVICE_TYPE_SERIAL_NOR,
    .sflash_pad_type        = SERIAL_FLASH_4PADS,    
    .serial_clk_freq        = FLEXSPI_SERIAL_CLKFREQ_100MHz,
    .sflash_a1size          = 8u * 1024u * 1024u,
    .data_valid_time        = {16u, 16u},
    /* .controller_misc_option = (1 << FLEXSPIMISC_OFFSET_PAD_SETTING_OVERRIDE_EN), */
    /* .cspad_setting_override =   1|(1<<3)|(3<<6),  */
    /* .sclkpad_setting_override = (7<<3)|(3<<6),  */
    /* .datapad_setting_override = (2<<3)|(3<<6),  */
    /* .dqspad_setting_override = 0, */

    .lookup_table           =
    {
      /* 0 - Quad Input/output read sequence - with optimised XIP support */
      [0]=FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x18),
      [1]=FLEXSPI_LUT_SEQ(MODE8_SDR, FLEXSPI_4PAD, 0xA0, DUMMY_SDR, FLEXSPI_4PAD, 0x04),
      [2]=FLEXSPI_LUT_SEQ(READ_SDR, FLEXSPI_4PAD, 0x04, JMP_ON_CS, 0, 1),

      /* 1 - Read Status */
      [1*4] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x01),
    
      /* 3 - Write Enable */
      [3*4] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, 0, 0),
    
      /* 4 - Write status */
      [4*4] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x01, WRITE_SDR, FLEXSPI_1PAD, 0x1), 

      /* 5 - Erase Sector */
      [5*4] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xD7, RADDR_SDR, FLEXSPI_1PAD, 0x18),
      
      /* 9 - Page Program */
      [9*4] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x02, RADDR_SDR, FLEXSPI_1PAD, 0x18),
      [9*4+1] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x8, STOP, FLEXSPI_1PAD, 0x0),
    
      /* 11 - Chip Erase */
      [11*4] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xC7, STOP, FLEXSPI_1PAD, 0x0),
    },
  },
  
  .page_size                = 256u,
  .sector_size              = 4u * 1024u,
  .blocksize                = 32u * 1024u,
  .is_uniform_blocksize     = false,
};

__attribute__((section(".boot_hdr.ivt")))
const struct ivt_s g_image_vector_table =
{
  IVT_HEADER,                         /* IVT Header */
  0x60002000,                         /* Image  Entry Function */
  IVT_RSVD,                           /* Reserved = 0 */
  (uint32_t)DCD_ADDRESS,              /* Address where DCD information is stored */
  (uint32_t)BOOT_DATA_ADDRESS,        /* Address where BOOT Data Structure is stored */
  (uint32_t)&g_image_vector_table,    /* Pointer to IVT Self (absolute address) */
  (uint32_t)CSF_ADDRESS,              /* Address where CSF file is stored */
  IVT_RSVD                            /* Reserved = 0 */
};

__attribute__((section(".boot_hdr.boot_data")))
const struct boot_data_s g_boot_data =
{
  FLASH_BASE,                         /* boot start location */
  (FLASH_END - FLASH_BASE),           /* size */
  PLUGIN_FLAG,                        /* Plugin flag*/
  0xFFFFFFFF                          /* empty - extra data word */
};

Drop me a note if you want an image to just try burning into the chip to see if it will boot from it...you should be able to do that from JLinkExe which would at least put to bed any concern over hardware issues.

Regards

DAVE

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

kerryzhou — Fri, 09 Aug 2019 02:17:18 GMT

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!

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

dmarples — Fri, 09 Aug 2019 06:41:50 GMT

I'm not aware of any need to change files in jlink, at least for the

1021...it may of course be different for the other chips. There is a need

to change jlink files when you're moving from hyperflash to qspi (there is

jlink documentation available on this) but not according to which bus

you've got your qpsi device connected to - provided you've not messed with

the fuses then that is set by the configuration pins.

Regards

Dave

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

kerryzhou — Fri, 09 Aug 2019 07:18:09 GMT

Hi Dave Marples,

You are right, the JLINK file which is needed to mofiy is the JLinkDevices.xml file, as you know, the default setting is used for Hyper Flash.

The option0 and option1 is used when download the code with MCUBootUtility, it is used to select the secondary pin mux.

Could you tell me your RT1020 with JLINK is based on which IDE? MCUXPresso or others, eg IAR, MDK?

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

amwilhite — Fri, 09 Aug 2019 15:06:34 GMT

Do you have a reference for the J-Link documentation for changing J-Link files when moving from Hyperflash to QSPI?

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

kerryzhou — Mon, 12 Aug 2019 02:08:11 GMT

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!

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

amwilhite — Mon, 12 Aug 2019 17:27:25 GMT

Dave,

Are you using a Quad SPI Flash that is different from the IS25WP064A populated on the EVK?

Can you comment on the changes you made to the flash config structure that differ from those listed in this thread?

Thanks

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

kerryzhou — Tue, 13 Aug 2019 02:10:38 GMT

Thank you for your valuable information!

Best Regards,

Kerry

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

dmarks_ls — Tue, 13 Aug 2019 18:12:40 GMT

Hi kerryzhou‌, jayheng‌,

Finally coming back around to try and get this working... regarding the MCU Boot Utility, I did modify my Boot Device Configuration to select "Has Option1" and "Enable Second Pinmux", but I'm still getting the error dialog that says

Bootable image is not generated successfully! Make sure you don't put the tool in path with blank space!

See my comment above where I detailed what was occurring. I've attached a text file (anonymized) of the output of the console window when I hit the "All-in-One Action" button. You can see from the output that I have the tool installed in a space-free directory path. Any ideas what's wrong with the Boot Utility?

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

dmarks_ls — Tue, 13 Aug 2019 20:45:47 GMT

Hi dmarples‌,

I see what you're on about with editing the boot header configuration... that does have to be customized to match the flash device that's in use on the board. Can you tell me what flash device you have on your RT1021 board? I need to reconcile some of what's in your source code with your device's datasheet. so I can better understand how to modify my code for our flash device. We're using a Cypress S25FL256L (datasheet), and I can see that its geometry and command set is slightly different from what you have defined.

David R.

Re: RT1050 - Debugging with QSPI flash on secondary pinmux

dmarples — Tue, 13 Aug 2019 21:00:57 GMT

I'm using the same devices as on the Eval Board, IS25LP064A. It's a while since I made the changes but IIRC you don't need _all_ of the entries in the boot header to bring it up (once I'd figured out the structure of the boot header, then it was easier to put them all in for the case I might need them later). I would recommend dropping one of these chips onto your board to remove a variable, then working back to your flash device.

Regards

DAVE