Unable to flash i.MX1052 using MCUXpresso GUI Flash Tool.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Unable to flash i.MX1052 using MCUXpresso GUI Flash Tool.

Jump to solution
361 Views
KinC
Contributor I

Hi! I am working with a custom board developed from the standard MIMXRT1050-EVKB with a RT1052 and a Windbond W25Q512JV. I tried flashing the SDK example flashloader onto my flash with two custom pin configurations that should boot up the LCD monitor on my board, using the GUI Flash tool. While the tool runs successfully without error, it seems that the tool didnt actually flash any image into the flash. The console log is as below:

-----------------------------------------

P&E GDB Server for Arm(R) devices, Version 9.33.00.00

Copyright 2018, P&E Microcomputer Systems Inc, All rights reserved

Loading library C:\nxp\MCUXpressoIDE_11.8.1_1197\ide\plugins\com.pemicro.debug.gdbjtag.pne_5.7.3.202310061729\win32\gdi\unit_ngs_arm_internal.dll ... Done.

Command line arguments: -interface=USBMULTILINK -port=USB1 -speed=5000 -flashobjectfile=C:\Users\<user>\Documents\MCUXpressoIDE_11.8.1_1197\workspace\evkbimxrt1050_flashloader\Debug\evkbimxrt1050_flashloader.axf -device=NXP_iMX_IMXRT1052 -programmingtype=0 -runafterprogramming -startserver -singlesession -quitafterprogramming

Device selected is NXP_iMX_IMXRT1052

User Specified Hardware Selection : Interface=USBMULTILINK and Port=USB1

Connecting to target.

Unable to load libusb0.dll

PEmicro Interface detected - Flash Version 11.22

Device is NXP_iMX_IMXRT1052.

Mode is In-Circuit Debug.

(C)opyright 2012, P&E Microcomputer Systems, Inc. (www.pemicro.com)

API version is 101

TARGET XML PATH is C:\nxp\MCUXpressoIDE_11.8.1_1197\ide\plugins\com.pemicro.debug.gdbjtag.pne_5.7.3.202310061729\supportFiles_ARM\target_v7m_vfp.xml

Server 1 running on 127.0.0.1:7224

Server 2 running on 127.0.0.1:7226

Server 3 running on 127.0.0.1:7228

Server 4 running on 127.0.0.1:7230

Server 5 running on 127.0.0.1:7232

Server 6 running on 127.0.0.1:7234

Server 7 running on 127.0.0.1:7236

Server 8 running on 127.0.0.1:7238

Server 9 running on 127.0.0.1:7240

Server 10 running on 127.0.0.1:7242

All Servers Running

Target Disconnected.
-----------------------------------------

It seems like the tool just terminated without doing anything.

I customised two GPIO pins to output on the LCD. It can be switched on without any error during debugging,
with the rest of the build identical to the SDK example.

I have built a custom .cfx with the correct flash device configurations and QE_bit_config.
I am also using an .arp for the flash that is unavailable in the IDE.

Debugging SDK example flexspi_nor_polling_transfer is also successful.

I understand that using MCUBootUtility is a more simple way to flash but both USB-HID and UART are unavailable options for my board.
I only have the option of JTAG through a P&E USB UNIVERSAL FX. 

I tried both flashing when the board was boot as serial downloader and internal boot,
and tried to boot the board in internal boot mode to see if the LCD is switched on.

Is there any flash specific configurations that I still need to alter to make this tool work?
Is there any alternative way for flashing? 
Thank you.

0 Kudos
Reply
1 Solution
288 Views
HangZhang
NXP Employee
NXP Employee

Hi @KinC 

It seems like you’re dealing with a complex issue involving custom configurations and potential tool limitations. Here are a few things you can check or try to resolve the flashing problem:

1. Verify .arp and .cfx File Configurations:
• Ensure that the .arp file you’re using correctly supports the Winbond W25Q512JV flash. Sometimes, custom .arp files might not fully align with the specific requirements of your flash memory or the RT1052. Double-check the configurations, especially the Quad Enable (QE) bit settings.
2. Review Pin Muxing:
• Confirm that the custom GPIO pin configurations for the LCD do not conflict with the FLEXSPI pin configurations. Incorrect pin muxing could prevent the flash from being correctly accessed.
3. Check FLEXSPI Settings:
• Review the FLEXSPI configuration in your flashloader project to ensure that the settings match the requirements of the W25Q512JV. Incorrect timing or command settings could lead to failed programming.
4. Alternative Flashing Method:
• Since you have confirmed that MCUBootUtility is not an option, you can try using the J-Flash tool by SEGGER, which is another robust tool for programming external flash memories. If you have access to a J-Link debugger, you could try this approach.

5. Test with Another Flash Algorithm:
• If you suspect the current flash algorithm is not working as expected, try experimenting with other compatible flash algorithms or tweaking the existing one to better suit your setup.
6. Double-Check Boot Mode:
• Ensure that the board is correctly configured in the desired boot mode before flashing. This might involve setting specific boot pins or jumpers to ensure the MCU is in the correct state to accept programming.

Hope this will help you.

BR

Hang

View solution in original post

0 Kudos
Reply
3 Replies
289 Views
HangZhang
NXP Employee
NXP Employee

Hi @KinC 

It seems like you’re dealing with a complex issue involving custom configurations and potential tool limitations. Here are a few things you can check or try to resolve the flashing problem:

1. Verify .arp and .cfx File Configurations:
• Ensure that the .arp file you’re using correctly supports the Winbond W25Q512JV flash. Sometimes, custom .arp files might not fully align with the specific requirements of your flash memory or the RT1052. Double-check the configurations, especially the Quad Enable (QE) bit settings.
2. Review Pin Muxing:
• Confirm that the custom GPIO pin configurations for the LCD do not conflict with the FLEXSPI pin configurations. Incorrect pin muxing could prevent the flash from being correctly accessed.
3. Check FLEXSPI Settings:
• Review the FLEXSPI configuration in your flashloader project to ensure that the settings match the requirements of the W25Q512JV. Incorrect timing or command settings could lead to failed programming.
4. Alternative Flashing Method:
• Since you have confirmed that MCUBootUtility is not an option, you can try using the J-Flash tool by SEGGER, which is another robust tool for programming external flash memories. If you have access to a J-Link debugger, you could try this approach.

5. Test with Another Flash Algorithm:
• If you suspect the current flash algorithm is not working as expected, try experimenting with other compatible flash algorithms or tweaking the existing one to better suit your setup.
6. Double-Check Boot Mode:
• Ensure that the board is correctly configured in the desired boot mode before flashing. This might involve setting specific boot pins or jumpers to ensure the MCU is in the correct state to accept programming.

Hope this will help you.

BR

Hang

0 Kudos
Reply
279 Views
KinC
Contributor I
Thank you for your reply.

My colleague just made it work yesterday using Keil and J-link, while I have made very little progress using my set up for the past week.
It feels like MCUXpresso's unique toolset still lacks much support and examples in documentations and drivers, but that may just be my lack of experience with this tool.

Thank you for your help once again.
Kin
0 Kudos
Reply
348 Views
KinC
Contributor I

Additional Info:
I noticed that the Flash tool used 

MCUXpressoIDE_11.8.1_1197\ide\plugins\com.pemicro.debug.gdbjtag.pne_5.7.3.202310061729\supportFiles_ARM\target_v7m_vfp

instead of my provided .arp to flash the image. Although I have already configured the debug configuration to use my dedicated .arp.

KinC_0-1723188494167.png

The dedicated .arp file will be used to erase the flash memory if I use the GUI Flash tool's 'Erase' function,
but it won't use it to flash, which is confusing.

 

0 Kudos
Reply