Title: RW612 Flash Programming Verification Failed at 0x08400000 on Murata Type 2FR EVK Hello NXP Community, I am using the Murata Type 2FR (LBES0ZZ2FR-EVK) based on the NXP RW612 MCU and need help resolving a flash programming issue. Initially, I followed the Murata Type 2FR Wi-Fi CLI project and its documentation. I successfully built and flashed the Wi-Fi CLI application and connected the device to a Wi-Fi network. After that, I tried the Wi-Fi MQTT example, which also worked successfully on the same board. However, after some time, I suddenly became unable to program new firmware into the device. Problem description I have tried flashing different firmware binaries at their respective addresses: Application firmware: 0x08000000 Wi-Fi firmware: 0x08400000 Bluetooth firmware: 0x08540000 I also tried reflashing the previously working Wi-Fi CLI and Wi-Fi MQTT projects, but the problem persists. I can connect to the RW612 using SEGGER J-Link over SWD, and I can read the existing flash contents. However, programming fails during flash verification. The issue occurs with different firmware images and is not limited to one project or address. I came across the NXP Community article titled “How to solve flashing problems in FRDM-RW612 (flash lock)” and tried to follow the suggested recovery approach using MCUXpresso Secure Provisioning Tool. However, I have not been able to resolve the problem. I also tried the ROM ISP recovery approach using USB and UART, but neither method worked successfully. When using the USB approach, blhost -- list-memory reports: Specified USB HID device not found: 0x1FC9, 0x0020 The device is visible in Windows Device Manager as a USB serial port (COM16), but the provisioning tool does not detect the expected USB HID device. Current J-Link error I am using J-Link Commander V8.44 with the RW612 target selected. The debugger successfully connects to the Cortex-M33 over SWD, and the target voltage is approximately 3.3 V. When programming the Wi-Fi firmware binary rw61x_sb_wifi_a2.bin at 0x08400000, I receive the following error: J-Link>loadfile "...\\rw61x_sb_wifi_a2.bin" 0x8400000
Downloading file [...]
J-Link: Flash download: Bank 0 @ 0x08000000: 1 range affected (589824 bytes)
J-Link: Flash download: Total: 4.538s
J-Link: Flash download: Program speed: 249 KB/s
****** Error: Verification failed @ address 0x08400000
Error while programming flash: Verify failed.
Unable to perform operation!
Command failed with exit code 1 The same general problem occurs when I try programming the application firmware and other previously working binaries. What I need help with Could this be caused by a flash write lock, security configuration, flash protection, or an incorrect flash programming algorithm? Is there a reliable procedure to recover or unlock the RW612 flash on the Murata Type 2FR EVK using MCUXpresso Secure Provisioning Tool? Can the FRDM-RW612 flash recovery procedure be safely applied to the Murata Type 2FR EVK? Are there any board-specific differences in entering ROM ISP mode? Since the debugger can connect and read flash contents, but programming fails verification, what should I check next? Is there a way to restore flash programming access without damaging the existing board configuration or permanently disabling debug access? I would appreciate a step-by-step recovery procedure, particularly for the MCUXpresso Secure Provisioning Tool and ROM ISP method. The board was previously working correctly with both the Wi-Fi CLI and Wi-Fi MQTT examples. The problem appeared later, without any intentional change to the hardware. Thank you for your help. Re: Title: RW612 Flash Programming Verification Failed at 0x08400000 on Murata Type 2FR EVK Hello @sakshee, hope you are doing well.
I will address your questions below:
> Could this be caused by a flash write lock, security configuration, flash protection, or an incorrect flash programming algorithm? The flash locking occurs when an application is written to the flash with an invalid flash configuration block (FCB), for example, when the application was built considering a different external flash device. In the case of the Murata Type 2FR it contains a different flash from the FRDM-RW612, hence, a different FCB is required for each board. Could you please confirm if an application build for the FRDM-RW612 was built and flashed to the 2FR EVK?
> Is there a reliable procedure to recover or unlock the RW612 flash on the Murata Type 2FR EVK using MCUXpresso Secure Provisioning Tool? If the previous case happened and the flash was locked, the reliable way to unlock it is as stated in the mentioned post: How to solve flashing problems in FRDM-RW612 (flash lock), however, this guide focuses on unlocking the FRDM-RW612. In order to apply this guide to the Murata's flash, I'd recommend following the general steps below (referencing both the Secure Provisioning Tool and the post itself):
Set the board to ISP mode.
Open the workspace, and select the RD-RW612-BGA option, as well as the "rdrw612bga_gpio_led_output_extfls.s19" source executable image.
Configure the UART interface.
Once in the main workspace menu, make sure the flash configurations match with the EVK's flash configurations in the Boot Memory Configuration window (please see the image below)
Follow the rest of the guide as-is.
> Can the FRDM-RW612 flash recovery procedure be safely applied to the Murata Type 2FR EVK? Are there any board-specific differences in entering ROM ISP mode? No, both boards have different flash memories each, therefore you must consider the steps shared in the previous answer. Also, I'd recommend checking the migration guide for RW612 development boards as it provides specific considerations regarding this same topic and application customization.
> Since the debugger can connect and read flash contents, but programming fails verification, what should I check next? Please first check the mentioned procedure and information and let me know your findings.
> Is there a way to restore flash programming access without damaging the existing board configuration or permanently disabling debug access? The shared procedure should not generate any damage to your board configuration, nor the debug access ports.
Please let me know if this helps.
View full article