RT1050 - Debugging with QSPI flash on secondary pinmux

dmarks_ls · ‎07-31-2019

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?

dmarples · ‎08-08-2019

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

View solution in original post

dmarples · ‎08-05-2019

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

kerryzhou · ‎08-05-2019

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!

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

Like • Show 0 Likes0 Reply

Actions

dmarks_ls · ‎08-07-2019

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.

kerryzhou · ‎08-07-2019

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!

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

kerryzhou · ‎08-02-2019

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

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

dmarks_ls · ‎08-05-2019

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

dmarks_ls · ‎08-02-2019

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