Hi,
I modified the download algorithm according to the above link,
https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT1170-Octal-flash-enablement/ta-p/1498369
and the programming function can be used normally, but I found that the Read back function has some minor problems, the content written is inconsistent with the content read, see the figure for details.I suspect it's caused by not configuring MPU.
Hi @kerryzhou :
The attachment RT-UFL-master is the Flash download algorithm I modified according to the operation in the following link. As you can see with git (Figure 1), the last modification is to adjust the Erase address range from 64M to 8M to avoid the Erase chip timeout.
https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT1170-Octal-flash-enablement/ta-p/1498369
The main phenomena of this failure are as follows: When I used J-Flash for Production Programming, the development board was Power on again, the program ran normally, and the Led blinked normally. When I used the read back function of J-Flash (Figure 2), The address range 0x3000 0000 to 0x301F FFFF is selected, and the read content is inconsistent with the written content (Figure 3). Then the development board is Power on again, and the program cannot run normally. At this time, the Jlink command is used to reconnect, and the content read is shown in Figure 4.
After re-using J-Flash for Production Programming, the development board is powered on again, and the program runs normally. At this time, Jlink command is used to connect. The content read again is shown in Figure 5, and the content is normal and consistent with the value written.
In summary, it appears that the use of J-Flash's Read back caused the Flash content to be tampered with. This fault has a great impact on our production and research and development, please help to check.
The file used for writing is: evkmimxrt1170_iled_blinky_octalFlash_cm7.bin (write from 0x3000 0000)
The file read out using J-Flash is saved as Read_back_0x3000_0000 to 0x301F_FFFF.hex; see the attachment for both.
The burning algorithm is MIMXRT_FLEXSPI_UV5_UFL.FLM, see attachment
Attached RT-UFL-master is the Flash download algorithm I modified according to the operation in the following link.
Attachment RT1176_octal.jflash is the J-Flash project.
The contents of JlinkDevices.xml are as follows:
Hi @许贻辉2023
I already reply you in your case, I have tested on my side octal flash with JFlash, readout data is correct.
Thank you for your interest in the NXP MIMXRT product, I would like to provide service for you.
Please tell me your used flash whole name.
In your post, you mention it is the hyperflash, but seems still the octal flash.
Please tell me whether it is MX25UM51345GXDI00, the same as the MIMXRT1170-EVK board?
This is important to identify the issues.
BTW, please use the same Segger JLINK driver as my post, v7.68b:
https://www.segger.com/downloads/jlink/JLink_Windows_V768b_x86_64.exe
or V7.88A:
https://www.segger.com/downloads/jlink/JLink_Windows_V788a_x86_64.exe
Whether the same issues or not?
If you are using the same octal flash as the MIMXRT1170-EVK board, please use the my post's app and the UFL.
Today, I test my octal flash board again, two driver version all works after reading:
So, I highly suspect your issue is caused by the old Segger JLINK driver.
Please try it again with new driver and my doc's attached UFL firmware and app.
Best Regards,
Kerry
Hi
I think you misunderstand me. The bin file I wrote is shown on the left side of the picture below, but the content I read out is shown on the right side. The reading in and writing out are inconsistent. See attachment for writing and reading files.evkmimxrt1170_iled_blinky_octalFlash_cm7.bin is the file to write.
Yes, the same failure still occurs, and I checked that the address does start at 0x3000 0000 when writing and 0x3000 0000 when reading, but the comparison is inconsistent. You can try it out with the downloaded algorithm from the tutorial. The same problem should arise.
I tried to use loadfile to download ".bin" file, the result is shown below, I found that there will be L1-verify and L2-verify.@kerryzhou
I think it may be that the behavior of "Read back" tampered with the content of Flash, making the data read back wrong and unable to pass the verification.I will present the evidence below.
