Showing results for 
Show  only  | Search instead for 
Did you mean: 
Not applicable

ERROR:Data2MEM:4 when downloading from the SDK to a xc7a35t

Jump to solution
I'm using Vivado 2014.1, retargeting a MicroBlaze project from a XC7K325T (KC705) to an Artix 7a35tftg256. The project Synthesizes, Implements and bitsteams. The .bit file downloads and runs on the target. I then export to the SDK and build a BSP and successfully get an ELF file.
When I attempt to download from the SDK, the download fails when creating the download.bit file. I see an error in the console: ERROR:Data2MEM:4 - Unrecognized device type in .bit file, '7a35tftg256'.
Searching for 'ERROR:Data2MEM:4' I found this link... discussion recommends using command 'data2mem - support' to see what chips are supported. My xc7a35t is not in the list and the closest thing supported is a xc7a100t. 
Any suggestions to get beyond this problem?
Options I'm investigating:
[] Find a newer data2mem with support for a xc7a35t. So far, I haven't located a newer download on
[] Find a way to manually run data2mem without specifying a part. I'm thinking that the part is irrelevant if the memory locations and corresponding data is known.
[] Find something other than data2mem to insert the .elf file into a downloadable .bit file. 


Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Not applicable

I have attached a PDF that shows you a possible workaround to this. This isnt pretty, but will get you around this untill this is fixed in the tools

View solution in original post

7 Replies
Not applicable

I have attached a PDF that shows you a possible workaround to this. This isnt pretty, but will get you around this untill this is fixed in the tools

View solution in original post

Not applicable


I tried stephenm's artix_data2mem.pdf which suggests adding the SDK's resulting .elf file to the Sources in Vivado which works - it embeds the .elf contents in Vivado's .bit output - but it's slow because I think a synth & imp & bitstream needs to be done each time the .elf is changed. 'Slow' meaning it takes about 20 minutes to change and test code vs 20 seconds. Maybe there's a shortcut I don't know about.


The PDF mentions running data2mem from the command line but I haven't tried that yet because I'm thinking that data2mem still won't know how to handle a xc7a35t.


By coincidence, 2014.2 was announced today - I tried it and got the same results. 

0 Kudos
Xilinx Employee
Xilinx Employee
Registered: ‎08-02-2007



I have tried to check the supported list of devices for data2mem in Vivado 2014.2 and it looks that xc7a35t is not included


So the work-around is to use the procedure mentioned by stephen



Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Not applicable
If you have an implemented design in Vivado, you will only need to run the write_bitstream command, you won't need to re-implement again.

I agree, this isn't a nice work
Registered: ‎11-09-2013

When will this be fixed??

0 Kudos
Registered: ‎07-25-2011


I'm having the same issue on xc7a35tcsg324.

I followed the guide (including the elf in the Vivado project) but it doesn't seem to work:

I tryed both the write_bitstream command and the full rebuild of the project.


My microblaze has only bram ram (no external bram) and the program fit in it.


Do I need to specify something in the linker script or add in some way the bootloop to the program?




Andrea Albano
bdSound srl
0 Kudos
Not applicable


We didn't need to touch the linker script to get this to work. Assuming that Vivado can download the configuration and the SDK can download the .elf, the steps to 'commit to flash' involve adding the .elf to the Vivado project and then running write_cfgmem to generate an MCS file. I've included an excerpt from my project notes below.



Build SPI Boot image for Artix

  • This assumes that
    • A Vivado project has been created
    • with a Block Design
    • with a MicroBlaze and
    • an SDK project has been created and
    • the project runs i.e., Vivado can download the configuration and the SDK can run the .elf file in the debugger.
    • The Vivado project must have the SDK’s .elf file added as a Design Source.  Detailed instructions are omitted here because I don’t remember the exact details. Each time the elf is updated, a new bitstream must be generated to include the new elf into the bitstream.
  • The steps below describe how to create a bootable SPI Flash image and how to download it. The process is different from the Zynq - the Zynq can be flashed from the SDK but the Artix must be flashed from Vivado. Data2MEM could be used to combine a bitstream and .elf into a downloadable image but Data2MEM doesn't support ‘small’ Artix chips like the 35T. The trick to get this to work is to add the .elf file as a Design Source which is unintuitive and seems like a chicken & egg scenario, but it works.
  • Build bitstream with new .elf
    • Copy the new .elf file created by the SDK into the location expected by Vivado. I keep a .bat file in the project’s root called UpdateElf.bat with these contents:

Rem copy .elf from SDK to project sources.

copy .\project.sdk\software\Debug\software.elf  .\project.srcs\sources_1\imports\Debug\software.elf

dir .\project.srcs\sources_1\imports\Debug\software.elf


    • After the copy, expect Vivado to indicate that the Implementation is Out-of-date as seen in the Design Runs window. If this is not the case, expect the next steps to be unsuccessful.
    • Build the bitstream(s) and expect the Implementation to indicate that it’s done.
  • Run a .tcl script to generate a .mcs file.  
    • The example script below generates 2 .mcs files - 1 for different sized FPGAs for our application. The outputs will be placed in the ./outputs directory (could optionally be called ./boot)

# Generate an MCS file for this project, to be downloaded to SPI Flash.

# 2014-06-13 Jim Fred

# Within the Vivado IDE, execute this script using menu: 'Tools / Run Tcl Script...'

# Ref:

# ----------------------

# Get the project's directory, .bit file and destination .mcs file paths.

set prjDir [get_property DIRECTORY [current_project]]

set bitFile100t $prjDir/[current_project].runs/impl_100t/TOP.bit

set mcsFile100t $prjDir/outputs/AdtiDpcaFpga100t.mcs

set bitFile35t $prjDir/[current_project].runs/impl_35t/TOP.bit

set mcsFile35t $prjDir/outputs/AdtiDpcaFpga35t.mcs

# Perform the work.

write_cfgmem -force -format mcs -size 32 -interface SPIx4 -loadbit "up 0x0 $bitFile100t" $mcsFile100t

write_cfgmem -force -format mcs -size 32 -interface SPIx4 -loadbit "up 0x0 $bitFile35t" $mcsFile35t

# End of file

    • How to run the script? In Vivado, use menu Tools / Run TCL script, select the script.  Expect to see results in the Tcl Console window (look for errors) and expect to see the generated files in the output directory
    • Optioinally, rename the output files with a date.
  • Download the .mcs file - Use either iMPACT or Vivado. We've been using Vivado by adding the appropriate SPI flash e.g., a  Micron 32Mbit N25Q32. Note that this configuration doesn't appear to get saved in the Vivado project so it needs to be repeated for each 'session' of downloading. 
  • Notes:
    • Compressed images download faster by a factor of 2x or 3x. This an option under Bitstream Settings, Advance settings (implemented design must be opened).
    • The SDK can download the .elf file to RAM (and optionally download the FPGA config) for quick and easy debugging but the SDK apparently cannot download the .elf to flash for small Artix chips.
0 Kudos