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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer wenorum
Observer
542 Views
Registered: ‎07-05-2016

ZCU111 flash problems after switching to Vivado 2019.1

My application uses the xilisf library.   This was all working when I was using Vivado 2018.2 (xilisf 5.11) but after switching to Vivado 2019.1 (xilisf 5.13) attempts to read or write the flash memory fail.  To check this further I copied 

xilinx/2019.1/SDK/2019.1/data/embeddedsw/lib/sw_services/xilisf_v5_13/examples/xilisf_qspipsu_stm_polled_example.c to my application to see what it reported.  Result:

QSPIPSU FLASH Polling Example Test
MISMATCH at 0 -- wrote F, read FF
QSPIPSU FLASH Polling Example Test Failed

The 'MISMATCH' line is from the line I added:

@@ -316,6 +316,7 @@
     for (UniqueValue = UNIQUE_VALUE, Count = 0; Count < MAX_DATA;
             Count++, UniqueValue++) {
         if (BufferPtr[Count] != (u8)(UniqueValue + Test_Polled)) {
+xil_printf("MISMATCH at %d -- wrote %x, read %x\r\n", Count, (u8)(UniqueValue + Test_Polled), BufferPtr[Count]);
             return XST_FAILURE;
         }
     }

Suggestions/fixes welcomed.

0 Kudos
4 Replies
Observer wenorum
Observer
527 Views
Registered: ‎07-05-2016

Re: ZCU111 flash problems after switching to Vivado 2019.1

I tried using the Xiilinx tools to program the flash after using XSDK->Xilinx0>Create Boot Image.  Here' the screen before attempting the programming:

FlashProg.pngXSDK->Xilinx0>Program Flash

This produced the following.   Not the most helpful error message....

program_flash -f /home/lxusers/w/wenorum/src/hsdBPM/hsdBPM.sdk/FSBL/bootimage/BOOT.bin \
-offset 0 -flash_type qspi-x8-dual_parallel -fsbl \
/home/lxusers/w/wenorum/src/hsdBPM/hsdBPM.sdk/FSBL/Debug/FSBL.elf -blank_check -verify \
-cable type xilinx_tcf url TCP:127.0.0.1:3121 

****** Xilinx Program Flash
****** Program Flash v2019.1 (64-bit)
  **** SW Build 2552052 on Fri May 24 14:47:09 MDT 2019
    ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.


Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-HW-Z1-ZCU111 FT4232H-93219A
	Device 0: jsn-HW-Z1-ZCU111 FT4232H-93219A-147e0093-0

Retrieving Flash info...

Initialization done, programming the memory
===== mrd->addr=0xFF5E0204, data=0x00000000 =====
BOOT_MODE REG = 0x0000
Downloading FSBL...
Running FSBL...
Finished running FSBL.
Problem in running uboot
Flash programming initialization failed.

ERROR: Flash Operation Failed
0 Kudos
Observer wenorum
Observer
490 Views
Registered: ‎07-05-2016

Re: ZCU111 flash problems after switching to Vivado 2019.1

I tried my application with Vivado 2018.3.   With this version QSPI flash writes seem to work using the xilisf library but reads seem to just lock up after some random number of calls to XIsf_Read. 

  • Vivado 2018.2 -- writes work, reads work
  • Vivado 2018.3 -- writes work, reads lock up after some varying number of calls to XIsf_RFead(....,XISF_QUAD_OP_FAST_READ,...)
  • Vivado 2019.1 -- writes don't work (it apears that bytes at even addresses are written properly, but bytes written at odd addresses are not)

Things seem to be getting progressively worse.

0 Kudos
Observer wenorum
Observer
456 Views
Registered: ‎07-05-2016

Re: ZCU111 flash problems after switching to Vivado 2019.1

  • Downloaded and reinstalled Vivado 2019.1.1
  • Created new projected using ZCU111 tempalte
  • Created block diagram system consisting of the ZYNQ proocessing section and a single AXI GPIO (DIP switches)
  • Built and exported to SDK
  • Created and ran 'hello world' example application
  • Added xilisf to board support package and configured serial flash family = 5 and serial flash interface = 3.
  • Copied 2019.1/SDK/2019.1/data/embeddedsw/lib/sw_services/xilisf_v5_13/examples/xilisf_qspipsu_stm_polled_example.c to application source directory, editted it to change main() to xilisf_qspipsu_stm_polled_example() and changed hello_world.c to call xilisf_qspipsu_stm_polled_example() after printing 'hello world'.
  • Compiled downloaded and ran modified hello world example which produced:
  • Hello World
    QSPIPSU FLASH Polling Example Test 
    QSPIPSU FLASH Polling Example Test Failed

So even Xilinx's example code doesn't seem to work any more.

Suggestions?

0 Kudos
Observer wenorum
Observer
420 Views
Registered: ‎07-05-2016

Re: ZCU111 flash problems after switching to Vivado 2019.1

Poking in to this a little further I discovered this comment in xilifs_erase.c:

 *      sk   02/15/19 4B Sector erase command is not supported by all QSPI
 *                    Micron flashes hence used used 3B sector erase command.

And this comment and code (in particular, the last four lines below) in xilifs_write.c:

 *      sk   02/15/19 4B write command is not supported by all QSPI Micron
 *                    flashes hence used used 3B write command.
...
#if ((XPAR_XISF_FLASH_FAMILY == SPANSION) && \
    (!defined(XPAR_XISF_INTERFACE_PSQSPI)))
        if ((InstancePtr->FourByteAddrMode == TRUE) &&
            (InstancePtr->ManufacturerID ==
                    XISF_MANUFACTURER_ID_SPANSION ||
             InstancePtr->ManufacturerID ==
                     XISF_MANUFACTURER_ID_MICRON ||
             InstancePtr->ManufacturerID ==
                     XISF_MANUFACTURER_ID_MICRON_OCTAL)){
            Command = XISF_CMD_PAGEPROG_WRITE_4BYTE;
#ifdef XPAR_XISF_INTERFACE_OSPIPSV
            if (InstancePtr->SpiInstPtr->OpMode == XOSPIPSV_DAC_MODE) {
                Command = XISF_CMD_OCTAL_WRITE_4B;
            }
#endif
            if (InstancePtr->ManufacturerID ==
                     XISF_MANUFACTURER_ID_MICRON) {
                Command = XISF_CMD_PAGEPROG_WRITE;
            }

 

So it appears that even if I figure out why 2019.1 is writing every other byte as 0 there will be no way to write more than 32 megabytes to the flash (!!!)   This is a big problem because the boot images that bootgen is creating are larger than 32 MB.

 

0 Kudos