03-01-2016 05:27 AM
I am experiencing the following issue with the Vivado 2015.4 Hardware Manager related to indirect programming of an SPI flash (Micron N25Q32, 3v3) connected to my FPGA (XC7A35T-1CSG325C).
Whenever the MCS contains partial data for a sector (e.g. a headerblock of 256 bytes to be written to a certain address), the tools correctly read back the complete 64K sector, erases it, and writes the modified contents back to the sector, except for the very last byte which doesn't get properly written back. Because of this the last byte of such a sector remains in the erased state (0xFF) and so the supposed-to-remain-untouched-data in my flash is corrupted.
Can someone confirm this behavior? And if yes, could Xilinx fix this?
03-02-2016 08:25 AM
@jods If there is issue will definately look into this. Can you please let me know the steps to reproduce the issue? I can use the AC701 board with N25Q256A Spi flash to reproduce the issue at my end.
03-03-2016 01:01 AM
just generate some small MCS file with some data in it, eg. (for a 4 MByte flash)
write_cfgmem -force -format MCS -size 4 -interface SPIx4 -loaddata "up 0x000000 MyFileWith256bytesData.bin" TestMCS
Using the Vivado Hardware Manager you can write this file into your flash. However before doing this, you need to readback the data which resides in your flash so you can compare afterwards. It is a bit silly that this seems not immediately possible in the Hardware Manager. You need first to write some other data (e.g. a bitfile) into your flash. In this way the fpga will become configured with the 'xilinx MCS flash design'. Next you can do a complete readback of the flash using:
readback_hw_cfgmem -force -all -format bin -file FlashContentsBeforeWritingTestMCS.bin
Next write the TestMCS into your flash and afterwards readback the contents with the readback_hw_cfgmem. Now compare both images. You will notice that the last byte of the sector where you have written this small TestMCS file will be corrupted (0xFF). I assume that your flash is also using 64K sectors, so this will be at byte offset 0xFFFF.
03-11-2016 11:42 PM
@jods I tried at my end but couldnt reproduce the problem. I did followed a bit different procedure, please check your message for more information
03-15-2016 03:11 AM
in attach you can find my binary file and the generated TestMCS.mcs.
File Format MCS
Start Address 0x00000000
End Address 0x003FFFFF
Addr1 Addr2 Date File(s)
0x00001000 0x000010FF Mar 15 10:01:04 2016 TestMCS.bin
When programming this into your flash only the zone from 0x1000...0x10FF should be changed.
But due to the bug, also the last byte of the 64K sector (offset 0xFFFF) will be left in an erased state (0xFF).
As told before: before writing this TestMCS.mcs into your flash, you should first readback the contents of your flash so you know which byte is currently at offset 0xFFFF. Are you able to readback the flash contents from your board? Do you have a hex compare tool to visualize and compare the bytes in the readback files?
I noticed another issue with the readback_hw_cfgmem: the -datacount option doesn't seem to work, here it always dumps the complete flash as if -all was specified. There is also a typo in the "-help" info of the readback_hw_cfgmem. One of the examples mentions 'readback_hw_cfgmem -offset -datacount 100' but this doesn't work since -offset has no parameter.