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.
Solved! Go to Solution.
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
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
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.
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.