RT1020 EVK cannot program to flash after replacing component -Ef(49)

cancel
Showing results for 
Search instead for 
Did you mean: 

RT1020 EVK cannot program to flash after replacing component -Ef(49)

876 Views
Contributor II

Update:

When putting the memory chip from EVK on the custom board it boots correctly and we are able to program it directly. So it must be something we are not doing on the new ICs that we need to do before it is able to be programmed this way.

Hi,

We have been using the EVK for some time for development and have moved on to create a custom board.

On the custom board we have done successful bringup by using the SWD interface from evalboard directly on custom board.

The custom board is using the exact same flash memory as the EVK (IS25LP064A-JBLE)

However we ran into some issues when trying to download to flash and the error we are getting is;

op ProgramPage (0x60000000, 0x200022B8, 0x4000) status 0x1 - driver reported driver error - EXTSPI driver rc 134 (0x86)
op ProgramPage (0x60000000, 0x200022B8, 0x4000) status 0x1 - driver reported driver error - EXTSPI driver rc 134 (0x86)
15: Target error from Commit Flash write: Ef(49): Flash driver operation gave error.
Debugging context: fell_driver_demo LinkServer Debug

pastedImage_2.png

To further debug the issue we took a brand new flash ic and mounted it on the RT1020 EVK and to our surprise we now get the exact same error on the RT1020 EVK.

  • Do we need to do some kind of initialization on the flash memory for it to work?

  • We have done mass erase from the GUI Flash Tool but that didn`t change anything.
Labels (1)
11 Replies

104 Views
Contributor II

We are experiencing the same problem with a custom RT1052 board.  We have the MCU mapped using the optional 'secondary pinmux' GPIO pins to our QSPI flash memory device (ISSI IS25LP016D-JBLE), which is a 16Mb (2MB) part.  We have pull-ups on the boot configuration pins BOOT_CFG[2:0] (GPIO_B0_14:GPIO_B0_12) to set the Flash Type to --- 111b - QSPI device supports 3B read by default (on secondary pinmux option).  We are able load the "evkbimxrt1050_flexspi_nor_polling_transfer" example project in RAM and run it.  It erases, writes, reads, and verifies the external QSPI flash device on our board.  However, we are not able to load our XIP bootable image using the MfgTool (blhost) over the (plain vanilla) UART (without an OpenSDA chip on our board) and receive the following message: "kStatus_FlexSPINOR_SFDP_NotFound", when using the blhost -V -p COM7,115200 -- configure-memory 0x09 0x2000 command.  We have tried several QCB (QSPI Configuration Block) option settings with the blhost -V -p COM7,115200 -- fill-memory 0x2000 0x04 0xC0000006; 0xC0000046 ('secondary pinmux' setting); 0xC0000106 (Quad Enable in bit 6 on this device); 0xC0000146, etc. None work.

pastedImage_743.png

A similar error is generated when attempting to load the "evkbimxrt1050_led_blinky" image using the MCUXpresso IDE via a LPC-Link2 over the SWJ-DP interface (using SWD).  We get this message:

pastedImage_1.png

When using the following Project Properties->C/C++ Build->MCU Settings:

pastedImage_4.png

Yet, again, when we load and run the "evkbimxrt1050_flexspi_nor_polling_transfer" example project from RAM, everything works as expected.

We are using MCUXpresso IDE v10.3.0 [Build 2200] [2018-12-03] and SDK_2.x_EVKB_IMXRT1050 version 2.4.2, manifest version 3.3.0.

Any help will be greatly appreciated.

Regards and thanks in advance,

-Roger

104 Views
Contributor III

Hi!

I just stumbled upon the same issue, and running the flexspi_nor_polling_transfer example does seem to solve it for me as well. Does anyone have any updates about any specific reason why that might be?

Thanks in advance!

Henrique

0 Kudos

104 Views
Contributor I

Hi,

the problem is the QE-Bit of the flash. Notice it is persistent, thats why it works after e.g. the flexspi-example was executed.

RT1051 and QSPI

Hope this solves your issues.

Michael

104 Views
Contributor I

Thank you,this demo app exactly solved the same problem with my RT1010. And I would like to share that I halted with "Link application to RAM". I am not sure whether this is a must?

0 Kudos

104 Views
Contributor III

Fantastic, thank you!

104 Views
Contributor III

I have run into what I believe is the same problem with my custom RT1052 board. I received prototypes of the custom board (the design and layout were 100% copied from the EVK).

I proceeded to use my P&E Micro Multilink Universal JTAG pod and the P&E progacmp flash programming application (which I had used successfully on the EVK) to try and erase and program the QSPI flash (IS25WP064A - same as the EVK). The erase didn't fail, and the programming didn't have any errors, but the verification failed on the first byte. I used the progacmp tool to show the FLASH contents and it was all 0xCC.

I next tried using the FLASH Utility in the MCUxpresso IDE. It claimed to erase the FLASH, but failed verification after programming. Connecting back to the P&E tools the FLASH still showed 0xCC.

After troubleshooting the QSPI interface and concluding it was working correctly, I went back to the NXP SDK and found the "flexspi_nor_polling_transfer" demo app. It loads into and runs out of RAM and will test both erasing and programming of the FLASH. I loaded the app via the P&E JTAG and then ran it. It was able to successfully erase and then program and verify the FLASH. Then I went back and tried both P&E progacmp and the MCUxpresso Flash Utility and now they both work as expected.

So, it does appear that the FLASH needs some type of initialization in order to work. Apparently, whatever the "flexspi_nor_polling_transfer" demo app is doing is sufficient to initialize the FLASH.

104 Views
NXP TechSupport
NXP TechSupport

Hi Fredrik Eriksen,

Semiconductor products and for the opportunity to serve you.

Do we need to do some kind of initialization on the flash memory for it to work?

-- I don't think so.

We have done mass erase from the GUI Flash Tool but that didn`t change anything.

-- I'd like to share the mechanism to erase IS25LP064A.
1. Download the Flash loader i.MX RT1020: https://cache.nxp.com/secured/assets/downloads/en/programmers/Flashloader_RT1020_1.0_GA.zip?__gda__=...
2. Download the flashloader image in the i.MX RT1020, then communicate with a running Flashloader using the blhost tool, you can learn how to do it by referring to the AN12238:

https://www.nxp.com/docs/en/nxp/application-notes/AN12238.pdf
3. In the Blhost tool, input the command flash-erase-all[memoryID] can perform an erase of the entire flash memory specified by memoryID.


Have a great day,
TIC

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

0 Kudos

104 Views
Contributor II

Thanks for answering.

Are you suggesting that the erase all option in GUI Flash Tool does not erase the memory correctly?

That this process is needed for a new memory chip?

0 Kudos

104 Views
NXP TechSupport
NXP TechSupport

Hi Fredrik Eriksen,

Thanks for your reply.
Actually, I'm not very clear with your new question, whether you can clarify it.
Have a great day,
TIC

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

0 Kudos

104 Views
Contributor II

Thank you for posting a reply.

My initial question was not how to erase the flash, but how to be able to program my fw to a new chip.

Since we are not able to get this to work, the questions are:

  • Does the new flash chip need to be erased before it can be written to?
  • Is GUI Flash Tool in MCU Xpresso not a valid way of erasing this flash memory?
  • Do we in fact need to erase the flash memory with Blhost tool first to be able to program fw into flash?

For your suggestion on using Blhost, in #2 you state to download the image in the RT1020. Do you mean just running debug from MCU Xpresso with checkbox "Link application ro RAM"? Since it cannot be downloaded to flash I think this must be the only possible way. However, if the file is an image, how do we actually get the FW into the Rt1020 ram?

"2. Download the flashloader image in the i.MX RT1020, then communicate with a running Flashloader using the blhost tool, you can learn how to do it by referring to the AN12238:

https://www.nxp.com/docs/en/nxp/application-notes/AN12238.pdf"

0 Kudos

104 Views
NXP TechSupport
NXP TechSupport

Hi Fredrik Eriksen,

Thanks for your clarification.
1) Does the new flash chip need to be erased before it can be written to?
-- No.
2) Is GUI Flash Tool in MCU Xpresso not a valid way of erasing this flash memory?
-- The GUI flash tool is able to erase the external flash.
 3_ Do we in fact need to erase the flash memory with Blhost tool first to be able to program fw into flash?
-- Blhost not only can erase the flash but also can validate whether MCU can communicate with the flash.
4) Do you mean just running debug from MCU Xpresso with checkbox "Link application ro RAM"?
-- No, please refer to the AN12238 to learn how to do it.
Have a great day,
TIC

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

0 Kudos