UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

FLASH erase not actually issuing erase

Reply
Highlighted
Voyager
Posts: 482
Registered: ‎04-04-2014

FLASH erase not actually issuing erase

Hi,

 

I am trying to use Hardware Manager to erase and blank check my configuration memory device, Spansion S25FL256 x4 single quad SPI. I have tried in Vivado 2017.2 and 2017.4. I am using a Zynq7000 xc7z045ffg676.

 

The log gives the following output

 

program_hw_cfgmem -hw_cfgmem [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7z045_1] 0]]
f probe 0 0 0
Performing Erase Operation...
Erase Operation successful.
INFO: [Xicom 50-44] Elapsed time = 0 sec.
Performing Blank Check Operation...
INFO: [Xicom 50-44] Elapsed time = 2 sec.
Blank Check Operation unsuccessful. The part is not blank.
ERROR: [Labtools 27-3161] Flash Programming Unsuccessful
program_hw_cfgmem: Time (s): cpu = 00:00:01 ; elapsed = 00:00:08 . Memory (MB): peak = 1279.070 ; gain = 0.000
ERROR: [Common 17-39] 'program_hw_cfgmem' failed due to earlier errors.

I have probed the PCB traces with a scope to see what is coming out of the Zynq during both the erase and blank check stages. In each case all I can see is the Zynq issuing a Read ID and the flash device then returning all the relevant manufacturer and device details as I would expect. At no point does the Zynq issue any kind of erase or try to read the device contents. Therefore, I am not surprised that it fails the test.

 

The clock would appear to be running at 16MHz and signals look clean.

 

Is there a reason why the device might not issue these commands? Has the manufacturer ID been returned incorrectly and therefore it has decided not to erase? If so why say the erase passed?

 

FWIW I know that the device and PCB are good, I am able to read and write form the device as expected using our production JTAG test tool. This uses the Zynq boundary scan cells to drive signals into the flash and read back what is returned, all at low speed.

 

Thanks

Moderator
Moderator
Posts: 1,500
Registered: ‎01-15-2008

Re: FLASH erase not actually issuing erase

looking at the log file message " part is not blank", there must be some block protection enabled in the flash. Since you mentioned you were able to program the flash with production jtag programmer, try to check if the block protection registers are enabled.

Otherwise if you have a new flash which was not programmed from the production jtag programmer, try to test with that.

Voyager
Posts: 482
Registered: ‎04-04-2014

Re: FLASH erase not actually issuing erase


@kknwrote:

looking at the log file message " part is not blank", there must be some block protection enabled in the flash. Since you mentioned you were able to program the flash with production jtag programmer, try to check if the block protection registers are enabled.

Otherwise if you have a new flash which was not programmed from the production jtag programmer, try to test with that.


Thanks for your reply. I am not totally convinced this is the problem, for a few reasons.

 

I am able to repeatedly erase, read and write using our production JTAG programmer. I wrote the test program and have complete, instruction level control over what happens during the test. 

 

Since I posted this yesterday I was able to successfully erase, blank check, program and verify using the SDK "Program Flash Memory" utility instead. I am new to using SDK and this was how I created the FSBL I was using with Hardware Manager, so I could have gotten that flow wrong. But, given I am able to do all the Flash QSPI accesses with SDK and my production programmer, the block protection can't be to blame.

 

If you take into account that I have also probed the QSPI bus with the oscilloscope and found that the only command issued is a Read ID, and it returns correct information form the device, block protection doesn't even come into it.

 

Just to be clear now, I am not saying there is definitely a problem with the Hardware Manager tool itself, as we have been able to program the Flash on a Microzed dev board using an example design. I think there probably is a mistake in our flow for generating the bootloader. I would welcome any suggestions there.

 

Thanks