QSPI Flash not detected on 2nd FlexSPI pinmux (i.MX RT 1021)

[bbenj]

Hello,

I'm trying to get working a custom board with a MIMXRT1021DAG5A which has a QSPI Flash (IS25LP128F-JBLE) on the 2nd pinmux option (BOOT_CFG[3:1] = 111), but I can't get the flash to be detected.

With boot config set to FlexSPI NOR on the secondary pinmux and internal boot, I tried the flexspi_nor_polling_transfert example (changing the pinmux to the 2nd flexspi option, using MCUxpresso config tools), running in RAM, but it gets stuck in flexspi_nor_enable_quad_mode (in a wait idle loop). I tried to change other config values, for which it doesn't get stuck, but the reads are wrong.

I also tried lowering the clock with no effects. Even at a low FlexSPI clock speed (36MHz) I can see that the CS line is pulsed low for less than 250ns, which doesn't seems right?

I also tested the example with the EVK and it's working with it (with the original pinmux).

I also tried MCU Boot Utility v2.0.0 (via USB), working on the EVK, but with my board it can't find the flash. Strangely, there is no activity on the 2nd flexspi pinmux option, but there is some on the default pinmux, which suggests that it doesn't use the right pins?

I'm a bit stuck right now, so any help would be welcomed.

First time using the i.MX RT but I didn't expect it would be so hard to get it working! I specifically used the same flash "model" of the EVK (just with more memory) to not have to deal with custom flash config and such.

I joined some schematics and the flexspi_nor_polling_transfert code I used.

All power lines are good, everything runs off 3V3, flash is powered, etc. The default FlexSPI pinmux is used for ethernet.

Thanks,

Benjamin

[kerryzhou]

Hi Benjamin Balga,

   How do you process the DQS pin in your board? Do you left it as floating or another purpose?

   If your DQS pin is used, your frequency will be limit to 60Mhz, could you please check it on your side?

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

[bbenj]

Hi kerryzhou‌,

The DSQ pin is used by the ENET, so definitely used and not floating.

The flash runs at 100MHz, it's what I have for my flash configs and what I measure on my scope. If I have time, I'll try with 133MHz.

Were does that 60MHz limit comes from? I looked briefly in the data sheets but couldn't find anything. Also, if the DSQ pin is really important, it would be useful to add a note in the HUG.

Benjamin

[kerryzhou]

Hi Benjamin Balga,

   Please check the RT1021 datahseet, you will find the related information.

  If you use the DQS pin, then you need to select the loop back internally, but the flash configuration option block is  default to readSampleClkSrc = 1, so you need to use readSampleClkSrc = 0 (internal loopback).

Please also configure the flexspi frequency to 60Mhz. Please check the following feedback from our internal side:

About the download, you also can use the blhost command line directly, you can provide a full fcb.bin with the readSampleClkSrc=0. You can use that to configure the memory before loading code.

• blhost -u – write-memory 0x2000 fcb.bin (write fcb.bin to SRAM address 0x2000)
• blhost -u -- configure-memory 0x09 0x2000 (configure QSPI using fcb.bin)

You also need to include the FCB in their application binary (might be easiest to build the full bootable image with  regular compiler—XIP_BOOT_HEADER_ENABLE=1). Then you can setup the FCB the way you want using what’s already in the SDK, build the application. Generate a binary of the application and extract the first 0x1000 bytes  of the image to create the fcb.bin to use the in the steps above.

If you have time, you can try it.

Any updated information, just 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.
-------------------------------------------------------------------------------

[samsaprunoff]

Good day Benjamin,

I am unsure if you saw my post about my troubles with my RT1021 design with the flash connected to secondary pinmux.  If not then it would be worth a read, as it may save you some debug time

https://community.nxp.com/thread/512805 

Effectively the publicly released MCUBoot Utility (ver 2.1.0) has a bug that prevents it from accessing the secondary pinmux on the RT1021. I battled with this for weeks and it was not until I connected with NXP in Austin that they confirmed the issue and found the bug in the flashloader.  In fact they sent me a new flashlooader to be used with the boot utility and it was closer to working, but it still was not 100%.  Sadly, because of my schedule and that I had no resolution in sight after about 3+ weeks of effort I decided to abandon the flash connected secondary pinmux location and redesigned my RT1021 design to have the flash connected to the primary pinmux like done on the EVK.  Doing this resulted in the flash working straight away with no issues or drama.  With that said I would not spend too much time battling with the Boot Utility until a new flashloader or version is released. 

Cheers,

Sam

[kerryzhou]

Hi samsaprunoff and Benjamin Balga,

   At first, thanks so much for both of your effort and contribution with NXP RT1021 chip.

  About the RT1021 secondary pinmux problem, it is really related to the flashloader, today, I check it with our MCUBootutility owner, he also tell me that the old flashloader prevent the secondary pinmux works with RT1021, just like samsprunoff said, it need to use the modified ivt_flashloader.bin, I also attach it, Benjamin Balga, if you have time, please copy my attached ivt_flashloader.bin to your MCUBootutility folder:

NXP-MCUBootUtility-2.0.0\src\targets\MIMXRT1021

replace the older one, then test it again, then share your result with me, thanks so much for your effort all the time.

About MCUBootutility 2.1.0, it is not the published version, it is still in the design phase.

RT chip is really a little new, so a lot of function need to do the testing, then we also need our customer's feedback, that's really very import to the RT ecology improvement.

About the ENET question in your new post, my colleague jeremy zhou already take it, and reply you.

If you have any further question, just reply that post directly, he will help you to get out!

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

[samsaprunoff]

Good day Kerry,

You are most welcome! I fully recognize that things like this do happen and especially so on new or newer devices. 

As mentioned to your colleagues I will send them one of my PCBs that the can use internally for secondary pinmux flash testing.  I am sure this will accelerate the debugging on your firm's side and potentially document issues or things to be aware of for other customers.

Cheers,

Sam

[kerryzhou]

Hi samsaprunoff,

  Thanks so much for your contribution, your information sharing is really very important to us. I am very glad that NXP have the customers like you and Benjamin, both of you give NXP powerful energy to move forward.

  Could you tell me my NXP colleague's name in Austin who provide service for you directly? I will contact with him internally.

Best Regards,

Kerry

[samsaprunoff]

Good day Kerry,

You are most welcome!  I will message you directly with the contact details.

Cheers,

Sam

[kerryzhou]

Hi Sam,

  Already get your message, I already send email to my colleagues.

  Let's keep in touch about this case in the community.

Best Regards,

Kerry

[bbenj]

Hi kerryzhou‌,

Thanks. I replaced ivt_flashloader.bin with your file and tried again (with every possible config), but I get the same errors as before.

If it may help, one thing that absolutely needs to be modified is the readSampleClkSrc of the memory config :

.readSampleClkSrc = kFlexSPIReadSampleClk_LoopbackInternally

Maybe something to check for the flashloader? For me, without this change the MCU cannot boot the flash.

Otherwise, all I can say is that the flash read/init part may be bugged as it reads wrong config values (flash size and such), and at one point it was working with the default config, as said previously.

Benjamin

[kerryzhou]

HiBenjamin Balga,

   Thanks for the updated information, I will try to get more information about the bugs in the flashloader especially for the secondary pinmux, as I know, the flashloader in default can't support the RT1021 secondary pinmux function, but our ROM bootloader can support it, that's why you modify the program algorithm which I told you, then you can program the secondary pinmux, that program algorithm call the ROM bootloader API directly.

   Anyway, I will try more effort, to help both of you.

   I still don't have the hardware which can support the secondary pinmux testing, so it blocked me to reproduce your problem, I will also transfer this situation to our hardware team, just try to find ways to get the testing platform.

  Any updated information, I will let you 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.
-------------------------------------------------------------------------------

[bbenj]

Hello Sam,

I saw your post indeed, and it was somewhat helpful because I followed what you were trying to do at the end: making the flash polling example to work, which I successfully done.

A hardware redesign is not an option for me sadly, so I kept trying. But lost a few weeks too, and if had known your issues sooner I surely would have modified my design (but at the time of your posts, my hardware was already sent to manufacture).

In the end I managed to make the secondary pinmux to work, though I do not fully comprehend how exactly (I had strange issues of it not working one day and working the next day without changing anything, and vice versa).

I had to modify the flash driver (for whatever reason NXP do not have/provide it!!) and the bootloader part of the app. I can't erase with my flash driver though, don't know why.

I can provide you my flash driver if you want to give it a try with your first hardware.

For the MCU Boot Utility, I have the 2.0.0 version, the latest available in the GitHub repo. Where did you get the 2.1.0?

I also couldn't make it to work, then it suddenly worked one day (and without using any special options), then stopped working the following day and ever since, without changing the hardware. So I guess there is a bug somewhere, yes. By bug in the flashloader, you mean something in MCU Boot Utility, or the MCU's own serial downloader?

I'm quite disappointed in NXP for the lack of resources with this MCU. Outside of the EVK examples there is basically nothing. Making the ethernet MAC to MAC to work will surely not be easy... :smileysad:

Cheers,

Benjamin

[samsaprunoff]

Good day Benjamin,

That is great that you were able to get something working.  I have found only one other NXP customer that has confirmed that their RT1021 design is working with the flash connected to the secondary pinmux (see Dave Marples' posts in RT1050 - Debugging with QSPI flash on secondary pinmux ).  Comparing the two designs I see some slight differences in the power connections, but in both cases both approaches are acceptable. 

What caused me a ton of grief (3+ weeks) was the fact that the MCUBootUtility would not work with the secondary pinmux connection regardless of the settings.  I used a logic analyzer and found that there was no activity on the flash pins and so I knew right away that somewhat was wrong beyond my design.  I also had a few times where something would work, but trying again it would not.  Given the elapsed time and that I felt that I could not reliably trust the secondary pinmux connection I decided to abandon this approach.  For me I could not take a chance on something not working in the field and thus it made sense for me to use what works, but importantly works reliably.

As for the NXP MCU Boot Utility... I downloaded it from Github and this was the latest version I received (2.1.0).  Testing further I downloaded the older versions (2.0.0. and older) and found these also did not work with the secondary pinmux.  It was only when I worked with NXP Austin that they reviewed the MCU Boot Utility flashloader code (  ivt_flashloader.bin which is the binary sent by the MCUBoot Utility for it to work with the target processor) that they found a reason why it was not working with the secondary pinmux flash connection.  They made some changes, recompiled, and sent me an updated flashloader that I used with the MCU Boot Utility and things were improving...Here I could actually see pin activity on the flash!  I  suspect if I had more time and/or sent my hardware to Austin that they could have sorted it out.  However, I could not wait any further and decided it best to redesign my PCB.   Secondly, I did not realize, but there is a performance bump if the flash is connected to the primary pinmux... so the redesign would have some other benefits too. 

As for NXP's efforts with the MCU... These days most companies ask their employees to do a lot more with less and so I imagine it is tough for all NXP staff to be up to speed on all their processors, etc.  Also, this processor family is still relatively new and so I imagine that more feedback from customers like you, me, etc will encourage them to provide more examples, etc in order to accelerate deployment efforts.  Ah... the joys being on the bleeding edge! 

If you do finally resolve all the issues please post up, as it would be great to have some concrete answers to this problem.

Cheers,

Sam

[bbenj]

Hi Sam,

I had the same issue with no signals on the flash I/Os, but that went away one day and I don't know why. I have no issue with it since, but as not knowing why, my trust in it is also limited... finger crossed!

I was aware of the possible performance reduction, but I didn't find really conclusive answers on that, if I remember correctly. I couldn't use the first pinmux even if I wanted anyway.

I hope all our efforts will be useful for others, at least.

I will update on the issue as I progress with it.

Benjamin

[samsaprunoff]

Good day Benjamin,

I am glad that I was not alone in the oddities I came across.  For a while there I thought it was time for me to hang up my soldering iron and compiler :smileyhappy:.

As for the oddities... At times I found that I had to reboot my computer, etc for things to restore themselves.  I was/am using MCUXpress, etc and so I was unsure if the reboot was because of the MCUXpress and/or the debugger drivers.  Needless to say I found that if something did arise I would reboot to see if this corrected it.  If not, then I would look deeper.

Too bad that you cannot use the primary pin mux, as this would potentially reduce your efforts in having a working platform.  I have to say I am very happy with my redesigned PCB, as I have yet to come across anything odd... so far anyway.

As for the performance bump on the primary pinmux, I was told to keep the DQS pin unconnected (GPIO_SD_B1_05), as internally this is used to "tune" the clock for maximum performance.  The secondary pinmux does not have this pin available and so I imagine the processor simply scales back the clock appropriately to ensure correct functionality.  Interestingly, the DQS pin is routed to an unpopulated sensor and so the flash performance would suffer if this sensor was ever populated.

Going further, I am contacting NXP in Austin to see if they still wish one of my earlier design PCBs so that they can test the secondary pinmux flash internally.  If so, then this would no doubt accelerate their debugging of all this and potentially get you sorted out quicker.

Lastly, you mentioned that you would send me your flash driver to try on my earlier design.  If so, please send this to me and I can quickly check to see if this works on my earlier design.  I like having explanations to issues, as this simply helps avoid future issues.

Cheers,

Sam

[bbenj]

Hi Sam,

Aha, same here :-P I also feared to see an errata update with a silicon issue on the secondary pinmux and no workaround x) That would have been bad.

I have issues with Windows USB driver that is, sometimes it says the serial downloader USB is not responding correctly and disables it. I have to reboot to be able to use it again.

Reboots could explain why it suddenly start to work, maybe. Some cache in MCUXpresso or things like that. Eclipse is so big it wouldn't surprise me.

I see for the performance bump. If I ever have to do a redesign, I will consider that (and probably go for a 1050 ou 1060 in the same time...).

Going further, I am contacting NXP in Austin to see if they still wish one of my earlier design PCBs so that they can test the secondary pinmux flash internally.  If so, then this would no doubt accelerate their debugging of all this and potentially get you sorted out quicker.

Nice, thank you for that.

I joined my .cfx flash driver, let me know how it works for you. Try the mass erase / sector erase with the GUI Flash tool if you can, they do not work for me (partially, at least part of the flash is erased, but I still get an error), but maybe...

Benjamin

[samsaprunoff]

Good day Benjamin,

Thanks for the flash driver!  I will give it a go later today.

As for the Windows USB Drivers... Do far I have not had any issues.  I am using the LPC-Link2 for my debugger, but I do have a PEMicro and J-Link on hand in case I run into any problems.  The other RT1021 customer (Dave Marples) is using J-link and all appears fine.

Also... I am still using Win 7 64-bit, as Win 10 still has oddities which has caused me grief.  Microsoft has and continues to make a lot of Win 10 core changes and I suspect that these changes also add to problems.  My Win 7 box has been solid and reliable and so I am sticking with it for as long as I can.

As for the other RT parts...understood.  In fact I already have a tray of RT1064's destined for another project.  The problem with the RT105x/106x parts is that the DRAM is a bit harder to get for me... Since I am involved in the Industrial sector our volumes are not overly high and so finding some of these parts can be a challenge in smaller-ish quantities.  The RT1021 is a nice fit and uses DRAM that is relatively cheap and available.

Cheers,

Sam

[bbenj]

Hi Sam,

Great!

I meant issues with Windows with the serial downloader of the RT1021, not with my debugger. I connect with MCU Boot Utility to my RT1021 via USB. When connecting to the flashloader, the USB re-instanciate with another VID/PID, and sometimes Windows doesn't like that.

I also use Win7, in a virtual machine (though I also tried with a "true" Win7 PC when I had issues). I work with macOS. I'm staying away from Win10 for as long as possible :smileysilly:

Another option of the RT105x/106x is being able to use a 250MHz or so flash, I think? In octal mode. But can't buy that everywhere...

We do not have overly large quantities either, and we're still at prototype stage. I was not feeling really confident with a BGA I couldn't bodge later if needed, so the RT1021 it was.

I'm also interested in the RT105x/106x for the (dual?) CAN FD they have.

We also looked at the boards from Embedded Artists (SODIMM modules), but it was a bit expensive and not really suited for us in the end (extra peripherals we didn't need like ethernet PHY and SDRAM, amongst other things).

Benjamin

[samsaprunoff]

Good day Benjamin,

Understood. I had some issues with MCUBootUtility and the USB interface as well... and to correct I had to do a reboot.  Thankfully this was not often and so I am unsure of it was the MCUBootUtility itself or perhaps the combination of it and MCUXpress and my various debuggers.

I congratulate you on your development environment!  Wow Win 7 under MACOs, you are brave!

As for BGA parts... Do not be too scared of these, as they are actually easier to mount than large pin QFPs.  The key is a proper stencil, paste, accurate placement, and a suitable temp profile.   Larger BGA pitches (e.g. 1mm) are more forgiving and I have had no issues even with some older and basic equipment.  The smaller pitches (0.8 and 0.65mm) I am using electropolished stencils, placement via my older PnP, and a suitable reflow oven... and so far no real issues.   I do find that the solder paste also plays a key role and so I purchase new paste if I have fine pitch parts to mount.

As for the off the shelf dimm modules... I have used a few in the past, but always found them annoying in that the mating connector was always in an inconvenient spot on my daughterboard, and the additional cost just did not make sense.  However, given the price and availability of suitable DRAM, at times the premade modules are actually cheaper than parts themselves.  I found this to be the case for a iMX6 Quad that I am using on another project.  The iMX6 + DRAM + support components actually exceeded the cost of the premade dimm.

Cheers,

Sam

[kerryzhou]

Hi Benjamin Balga,

   Thanks a lot for your updated information.

   You said, now, just the MCUBootutility write, erase and read can't work.

   But the debugger still works with CMSIS DAP, just the mass erase can't work, right?

    Could you share your modified flexspi_nor_config.c, MIMXRT1020-IS25LP128-FLEXSPI2.cfx or the related source code detail modify points for secondary pinmux option? When you debug the code, do the mass erase for the external flash, do you use this erase whole chip?

What about erase sector, whether it works or not?

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