Jump to content
  • 0

CMOD A7: Possible broken Flash - How can I diagnose this


PeterM

Question

All:

I've been incrementally developing both hardware (MicroBlaze with AXI peripherals) and software for the MicroBlaze itself.  I've set up my software program size so that all software and hardware configuration can fit into a single .bit file.

I've been able to program the flash several times, but yesterday have been getting errors while attempting to erase the flash.  Notes are below.

Is there a HW/SW program I could load onto the FPGA to prove or disprove that the flash is broken?

Thanks!!

Peter

From the Vivado side:

create_hw_cfgmem -hw_device [lindex [get_hw_devices] 0] -mem_dev [lindex [get_cfgmem_parts {n25q32-3.3v-spi-x1_x2_x4}] 0]
set_property PROGRAM.ADDRESS_RANGE  {use_file} [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]
set_property PROGRAM.FILES

  1. [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0]]
    set_property PROGRAM.UNUSED_PIN_TERMINATION {pull-none} [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]
    set_property PROGRAM.BLANK_CHECK  0 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]
    set_property PROGRAM.ERASE  1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]
    set_property PROGRAM.CFG_PROGRAM  1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]
    set_property PROGRAM.VERIFY  1 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]
    set_property PROGRAM.CHECKSUM  0 [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]
    startgroup 
    if {![string equal [get_property PROGRAM.HW_CFGMEM_TYPE  [lindex [get_hw_devices] 0]] [get_property MEM_TYPE [get_property CFGMEM_PART [get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]]]] }  { create_hw_bitstream -hw_device [lindex [get_hw_devices] 0] [get_property PROGRAM.HW_CFGMEM_BITFILE [ lindex [get_hw_devices] 0]]; program_hw_devices [lindex [get_hw_devices] 0]; }; 
    INFO: [Labtools 27-3164] End of startup status: HIGH
    program_hw_cfgmem -hw_cfgmem [get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]]
    Mfg ID : 20   Memory Type : ba   Memory Capacity : 16   Device ID 1 : 0   Device ID 2 : 0
    Performing Erase Operation...
Erase Operation failed.
ERROR: [Labtools 27-3161] Flash Programming Unsuccessful
ERROR: [Common 17-39] 'program_hw_cfgmem' failed due to earlier errors.

 

From the XSDK side:

bootgen -arch fpga -image \
/home/pmeyer/WORK/DA-Test/ChameleonFPGA/UARTSlaveController/UARTSlaveController.sdk/top_hw_platform_0/cache/bootimage.bif \
-w -o \
/home/pmeyer/WORK/DA-Test/ChameleonFPGA/UARTSlaveController/UARTSlaveController.sdk/top_hw_platform_0/cache/BOOT.bin \
 -interface spi 

program_flash -f \
/home/pmeyer/WORK/DA-Test/ChameleonFPGA/UARTSlaveController/UARTSlaveController.sdk/top_hw_platform_0/cache/BOOT.bin \
-offset 0x00000000 -flash_type n25q32-3.3v-spi-x1_x2_x4 -blank_check -verify -cable type \
xilinx_tcf url TCP:127.0.0.1:3121 

****** Xilinx Program Flash
****** Program Flash v2016.3 (64-bit)
  **** SW Build 1682563 on Mon Oct 10 19:07:26 MDT 2016
    ** Copyright 1986-2016 Xilinx, Inc. All Rights Reserved.

Connecting to hw_server @ TCP:127.0.0.1:3121

Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-Cmod A7 - 35T-210328A2B5A8A
    Device 0: jsn-Cmod A7 - 35T-210328A2B5A8A-0362d093-0

Retrieving Flash info...

Initialization done, programming the memory
Performing Erase Operation...
Erase Operation failed.

ERROR: Flash Operation Failed
Server disconnected during TCF command
/home/pmeyer/3rdParty/SDK/2016.3/bin/loader: line 164: 20344 Segmentation faul

Link to comment
Share on other sites

13 answers to this question

Recommended Posts

All:

Just to add to this:

If I power cycle the FPGA, I am able to "Program FPGA" without a problem.

If I attempted to "Program Flash" (and it failed with an erase error).  I need to power cycle the device before attempting to "Program FPGA"

Peter

Link to comment
Share on other sites

All:

More information: I attempted to just write to the device without erasing it (using no-erase option in program_flash).  Here is what I get.

Peter

program_flash -f /home/pmeyer/WORK/DA-Test/ChameleonFPGA/UARTSlaveController/UARTSlaveController.sdk/top_hw_platform_0/cache/BOOT.bin -no_erase -offset 0x00000000 -flash_type n25q32-3.3v-spi-x1_x2_x4 -verify -cable type xilinx_tcf url TCP:127.0.0.1:3121
WARNING: [Common 17-259] Unknown Tcl command 'program_flash -f /home/pmeyer/WORK/DA-Test/ChameleonFPGA/UARTSlaveController/UARTSlaveController.sdk/top_hw_platform_0/cache/BOOT.bin -no_erase -offset 0x00000000 -flash_type n25q32-3.3v-spi-x1_x2_x4 -verify -cable type xilinx_tcf url TCP:127.0.0.1:3121' sending command to the OS shell for execution. It is recommended to use 'exec' to send the command to the OS shell.

****** Xilinx Program Flash
****** Program Flash v2016.3 (64-bit)
  **** SW Build 1682563 on Mon Oct 10 19:07:26 MDT 2016
    ** Copyright 1986-2016 Xilinx, Inc. All Rights Reserved.

Connecting to hw_server @ TCP:127.0.0.1:3121

Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-Cmod A7 - 35T-210328A2B5A8A
    Device 0: jsn-Cmod A7 - 35T-210328A2B5A8A-0362d093-0

Retrieving Flash info...

Initialization done, programming the memory
Performing Program and Verify Operations...
0%...10%...Program/Verify Operation failed.
ftdi_read_data failed: usb bulk read failed

ERROR: Flash Operation Failed
ftdi_read_data failed: usb bulk read failed
xsct% child process exited abnormally

Link to comment
Share on other sites

PeterM,

This definitely sounds like a flash issue. In order to confirm that it's the hardware, you could run through the Getting Started with Microblaze tutorial, add the quad spi to the project with a 50MHz clock, then run through the How to Store Your SDK Project in SPI Flash tutorial. This might not be the fastest test, but it could be helpful for us to know what step this process fails on. I don't know of any other Microblaze examples or demos to try for the Cmod A7 specifically.

Hope this helps,

Arthur

Link to comment
Share on other sites

@PeterM,

You may also wish to try power cycling your device.  Just reloading the FPGA configuration will not reset the flash back to its reset/power-on configuration.  Chances are, however, that a power cycle will take the flash out of any difficult modes it may have gotten into.  (Be careful that you do not power cycle it during an erase/program operation, lest the result be less than certain.)

 

That said, power cycles may not necessarily fix things.  The particular flash that Digilent is using on the CMod-A7 is very similar to the one on the Arty that I've been working with.  I recently wrote a full/complete controller for it as part of my OpenArty project.  (My apologies if adjusting this for your platform is non-trivial, the Verilog though will run the chip through its paces.  A second/control program, wbregs, can be used to read/write the various registers on this chip from your host PC whereas wbprogram can be used to program it--if it is in its default mode.)

One of the problems with the Extended QSPI flash protocol that this chip uses, is that it has several "modes" it can be in.  For example, when the chip is in XIP mode it will not accept commands, but only addresses with an assumed read command.  Other configurations can change the number of idle bits the chip will expect between receiving and writing data.  This XIP mode in particular makes flash access really fast when you want the chip to act like a ROM memory, but it's not so good when you want to erase/program sectors.  Adding fuel to this difficult fire, the chip also has several non-volatile settings associated with it.  The most difficult of these are associated with the non-volatile configuration register, although the status register has some non-volatile write-protection settings within it as well.  In other words, if you aren't careful with the commands you send to the flash device, it could easily end up with a non-volatile configuration "mode" so that cycling the power will not fix it.  Such modes include such things as 1) starting in XIP mode (where it accepts addresses, not commands), 2) expecting the wrong number of dummy clock cycles prior to any data becoming valid, or even 3) setting the device into a mode where the data does not read from it sequentially.  I think the Xilinx configuration utilities can handle the incorrect number of dummy cycles, but the XIP mode could make things difficult.

I'd love to say I have an answer that can recover the chip from all modes, but to be honest I've gotten stuck in some of the chips modes and later gotten out ... I'm not necessarily certain how.  I think I tried "reading" from the device at address zero, or maybe it was the all ones address, which then put the controller into XIP mode--regardless of the mode it was in, from which reading a register would take it out of XIP ... or something similar to that.

Dan

Link to comment
Share on other sites

Hi:

So far, I've need the power cycle to re-load my FPGA after a failed attempt to erase while programming the flash.  That said, your comments suggest that the previous FPGA application installed might subvert a subsequent attempt to program.

Let me try flashing it after power cycling the A7.

Thanks!

 

Peter

Link to comment
Share on other sites

Hi Arthur:

I think I've programmed this flash about 5 time, and it just stopped working yesterday.  The error seems to be around erasing the flash.  I've also attempted to "program_flash" with the -no_erase option and it fails on a bulk read.

One (more Xilinx) question: if the page protection bits were set, does the "program_flash" have the awareness of this and is it able to disable the protection.
Is this flash simply broken? (I wish I had a second CMOD A7 to swap in to my breadboarded layout.)

Thoughts?

Peter

Link to comment
Share on other sites

Hi Arthur:

So I ran throught the tutorials as suggested.

I was able to flash the software (.elf) file to offset 0x00300000 

I was not able to program the hardware at offset 0x00000000

I am now convinced this is not a register issue, but that I have a damaged flash.  Who can I speak to about an RMA?

Peter

Link to comment
Share on other sites

All:

ROOT PROBLEM FOUND!!!!!

It was the USB cables.  (2 different ones preventing the flash from programming), I left my default cable at the office and used another this morning.  My office setup had a powered USB hub that I connected my default cable to.  My experiments this morning was with a different cable directly connected to a USB3 port on my laptop.

I swapped for a third cable, and the programming worked.  

I would guess that the first two cables could not push the current required to erase the flash memory.   ...not the first time I've had problems with the B style connectors........

Let's call this matter closed.

Peter

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...