kStatusMemoryVerifyFailed when bin is greater than 28kB

[dachancellor]

We are working with a custom board containing an RT685.  We have a serial NOR flash chip connected to SPI1 that we use to store our application. On reset, the program stored in the serial NOR flash is loaded into RAM and executed.  We have been able to get this portion of execution setup correctly and functioning by using the MCUBootUtility GUI.

Our basic "hello world" program has worked with no issues.  However, since we have been adding functionality and the size has grown, we are no having an error when trying to use the MCUBootUtility to store our application in the serial NOR flash.  The serial NOR is configured as 1 bit NOR Flash, Page size 256b, Sector size 4Kb, Total size 16384Kb.

When the bootable image created is less than 28kB, this is the output from MCUBootUtility:

'Connect to xxx' button is clicked
Executing blhost2_3\win\blhost -t 5242000 -u 0x1FC9,0x0020 -j -- fill-memory 1097728 4 3222275328 word
Executing blhost2_3\win\blhost -t 5242000 -u 0x1FC9,0x0020 -j -- fill-memory 1097732 4 0 word
Executing blhost2_3\win\blhost -t 5242000 -u 0x1FC9,0x0020 -j -- configure-memory 272 1097728

'Generate Bootable Image' button is clicked
User image file has been converted to S-Records successfully

'Load Bootable Image' button is clicked
Executing blhost2_3\win\blhost -t 2048000 -u 0x1FC9,0x0020 -j -- flash-erase-region 4096 28672 272
Executing blhost2_3\win\blhost -t 5242000 -u 0x1FC9,0x0020 -j -- write-memory 4096 app_unsigned.bin 272

When this completes, the processor can be reset and the program runs.

However, when we have a bootable image that is slightly larger (>28kB), the final step fails with error 10207 - kStatusMemoryVerifyFailed.
An error dialog box states "Failed to flash bootable image into external memory. Please reset board and try again."

'Connect to xxx' button is clicked
Executing blhost2_3\win\blhost -t 5242000 -u 0x1FC9,0x0020 -j -- fill-memory 1097728 4 3222275328 word
Executing blhost2_3\win\blhost -t 5242000 -u 0x1FC9,0x0020 -j -- fill-memory 1097732 4 0 word
Executing blhost2_3\win\blhost -t 5242000 -u 0x1FC9,0x0020 -j -- configure-memory 272 1097728

'Generate Bootable Image' button is clicked
User image file has been converted to S-Records successfully

'Load Bootable Image' button is clicked
Executing blhost2_3\win\blhost -t 2048000 -u 0x1FC9,0x0020 -j -- flash-erase-region 4096 32768 272
Executing blhost2_3\win\blhost -t 5242000 -u 0x1FC9,0x0020 -j -- write-memory 4096 app_unsigned.bin 272

As bolded and underlined above, the only difference in the commands is the amount of flash erased to fit the program.  I would guess that it has to do with crossing some sort of boundary ? Our serial NOR flash appears to be configured correctly as it works on the smaller file size.

Any suggestions ? 

Thanks,
Chandler

[jeremyzhou]

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
I think I need more information, so I was wondering if you can share the part number of Nor flash and the schematic about connecting the flash.
In addition, I hope you can introduce the configuration of MCUBootUtility to contact your custom board
Looking forward to your reply.

Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[dachancellor]

I've attached the relevant portions of the schematic.

Our chip is a Cypress S25FS128.

I believe the connections are fine as program sizes smaller than 28KB will write and verify without issue.

The information in my previous post shows the configuration within MCU Boot Utility as well as the blhost commands that are sent by the GUI.

Our connection is over USB.

As stated before, the application file size growing past 28kB, resulting in blhost erasing 32kb and writing the application at the 4096 address is the issue.

Thanks in advance for your reply.

Chandler

[jeremyzhou]

Hi,
Thanks for your reply.
I'd like to know whether the issue happens in all custom boards, and I'd like to suggest you input the command manually to contact the Nor Flash and extend the area when executing the flash-erase-region command, for instance
blhost2_3\win\blhost -t 2048000 -u 0x1FC9,0x0020 -j -- flash-erase-region 4096 65536 272
Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[dachancellor]

Thanks for the response. 

I stumbled into this when troubleshooting yesterday.  I had tried erasing larger regions, and blhost would respond and say it was successful, but then it still failed to write with a memory verify fail.

I then used read-memory commands see what was goin on at the 0x8000 address and noticed that the first page was all 00s (incorrect since it should be erased to FF) and that the rest of the 4kb sector after the first page was random values (and not FF as it should have been).

It seems like there was a "bad page" or for some reason blhost wasn't able to erase/write that sector, even though the erase region command returned success.

I then tried a flash-erase-all, which DID successfully erase that page and sector and I was able to program my larger file with no errors.

This would have been a little easier to track down had blhost returned an error for the flash-erase-region command.

Thanks,

Chandler

[jeremyzhou]

Hi,
Thanks for your reply.
I'd like to know whether the above issue happens in all custom boards.
Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------