cmod a7 flash program using Adept 2 or xc3sprog

[charkster]

Hi,

I am able to program my CMOD A7-35t FPGA using either Adept 2 or xc3sprog.

Using Adept 2 (after downloading and installing the runtime and utility deb files):

djtgcfg enum

djtgcfg prog -d CmodA7 -i 0 -f design.bit

 

Using xc3scprog (after sudo apt-get install xc3sprog):

xc3sprog -c jtaghs1_fast -T

xc3sprog -c jtaghs1_fast design.bit

 

I am not able to see a flash device with either Adept 2 or xc3sprog. All I can see is one device, the FPGA.

Is there a way to program the flash memory with either Adept 2 or xc3sprog?

Thanks.

 

I created the MCS files... would I need to use openocd through the FT2232H on the cmod a7? Is there a template for writing to the Micron memory? 

Edited February 17, 2021 by charkster

[xc6lx45]

Hi,
with xc3sprog I believe you'll have to compile the programming bitstream for your target device as it's not included.

You may also need to make minimal changes to the executable e.g. add the vendor ID (if I remember correctly). The hard part is setting up the build process with CMAKE etc. Expect to spend a working day or two on this.

The attached programming file did work with Artix on a Trenz module (not tried specifically with CMOD A7). You'll have to put in correct constraints for the chip in question and build with Vivado, then have xc3sprog load it as programmer bitstream.

 

xc3sprog.zip

[JColvin]

Hi @charkster,

I don't know about xc3sprog, but I know it's frustrating to get the flash programmed through Adept. Adept does not support .mcs files, only .svf files. However, as detailed a bit further in this forum thread post, https://forum.digilentinc.com/topic/20357-program-arty-s7-25-spi-flash-with-digilent-adept/?do=findComment&comment=57677, I wasn't able to get the .svf file to work as expected in either Adept or even through the Vivado Hardware Manager.

The consistent solution I have found was to load a .bin file through the Vivado Hardware manager (you can use the lighter weight Vivado Lab Tools rather than the full Vivado installation to do this), but I realize that's not always convenient in some work environments.

Thanks,
JColvin

[charkster]

Thanks @JColvin & @xc6lx45 ! I am new to Adept and xc3sprog so I thought I would ask.

@xc6lx45, I am assuming that programming your design will allow xc3sprog to detect the flash scan chain or is the flash memory also programmed when I program the FPGA?

Thanks again... I don't mind a 2 step process.

In looking at the pin constraints file, I am assuming that I will need to map MOSI_ext, MISO_ext, IO2, IO3 and CSB_ext to the proper pins of the CMOD A7 board.

CMOD A7 board schematic

Github pin constraints for CMOD A7

Here are my pin constrain changes for CMOD A7:

# #################################################
# RED LED
# #################################################
#set_property PACKAGE_PIN M16 [get_ports RLED]
#set_property IOSTANDARD LVCMOS33 [get_ports RLED]
set_property -dict { PACKAGE_PIN C17   IOSTANDARD LVCMOS33 } [get_ports { RLED }]; #IO_L14P_T2_SRCC_16 Sch=led0_r

# #################################################
# dummy green LED
# #################################################
#set_property PACKAGE_PIN M18 [get_ports GLED]
#set_property IOSTANDARD LVCMOS33 [get_ports GLED]
set_property -dict { PACKAGE_PIN B16   IOSTANDARD LVCMOS33 } [get_ports { GLED }]; #IO_L13N_T2_MRCC_16 Sch=led0_g

# #################################################
# SPI MOSI
# #################################################
#set_property PACKAGE_PIN K17 [get_ports MOSI_ext]
#set_property IOSTANDARD LVCMOS33 [get_ports MOSI_ext]
set_property -dict { PACKAGE_PIN D18   IOSTANDARD LVCMOS33 } [get_ports { MOSI_ext }]; #IO_L1P_T0_D00_MOSI_14 Sch=qspi_dq[0]

# #################################################
# SPI MISO
# #################################################
#set_property PACKAGE_PIN K18 [get_ports MISO_ext]
#set_property IOSTANDARD LVCMOS33 [get_ports MISO_ext]
set_property -dict { PACKAGE_PIN D19   IOSTANDARD LVCMOS33 } [get_ports { MISO_ext }]; #IO_L1N_T0_D01_DIN_14 Sch=qspi_dq[1]

# #################################################
# SPI WP/IO2
# #################################################
#set_property PACKAGE_PIN L14 [get_ports IO2]
#set_property IOSTANDARD LVCMOS33 [get_ports IO2]
set_property -dict { PACKAGE_PIN G18   IOSTANDARD LVCMOS33 } [get_ports { IO2 }]; #IO_L2P_T0_D02_14 Sch=qspi_dq[2]

# #################################################
# SPI HOLD/RESET/IO3
# #################################################
#set_property PACKAGE_PIN M14 [get_ports IO3]
#set_property IOSTANDARD LVCMOS33 [get_ports IO3]
set_property -dict { PACKAGE_PIN F18   IOSTANDARD LVCMOS33 } [get_ports { IO3 }]; #IO_L2N_T0_D03_14 Sch=qspi_dq[3]

# #################################################
# SPI CS
# #################################################
#set_property PACKAGE_PIN L13 [get_ports CSB_ext]
#set_property IOSTANDARD LVCMOS33 [get_ports CSB_ext]
set_property -dict { PACKAGE_PIN K19   IOSTANDARD LVCMOS33 } [get_ports { CSB_ext    }]; #IO_L6P_T0_FCS_B_14 Sch=qspi_cs

set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property BITSTREAM.CONFIG.CONFIGRATE 66 [current_design]
set_property CFGBVS VCCO [current_design]
set_property CONFIG_VOLTAGE 3.3 [current_design]

 

Edited February 17, 2021 by charkster

[xc6lx45]

Yes, two steps. First it uploads the attached bitstream to the FPGA, then that is used to access the flash. 

I think it detects the flash by reading some vendor ID from standardized registers (there is no "scan chain", the flash is not on JTAG but SPI). And yes, the  pins in question go to the flash memory.

Note, the last two lines of the constraint file are important but I think they match the regular CMOD A7 constraints file (but please check).

[charkster]

@xc6lx45 Thanks! I have made the new bit file (I called it "xc3sprog_first.bit"). No problems that I could see with the pin constraints file... I checked the log file. I am able to load it into the CMOD A7 and I see the RED led on. I am not seeing anything new when running 

djtgcfg enum

or

xc3sprog -c jtaghs1_fast

Also, I had to guess on the MISO_ext pin in the constraints file... it connects to "qspi_dq[1]" in the schematic. Not sure if that is correct.

Thanks again.

Edited February 17, 2021 by charkster

[JColvin]

Yes, you will not see anything when you run commands to detect the JTAG devices as the SPI flash is not on the JTAG scan chain (as @xc6lx45 mentioned); as far as I am aware there is not a way to change this detail.

I believe the MISO pin you have assigned to qspi_dq[1] / D19 is correct based on page 11 of the Micron datasheet. It was labeled differently in the Digilent .xdc because in QSPI mode it's not exclusively used in one data direction.

Thanks,
JColvin

[charkster]

@JColvin, thank you for the details. I will look closer at the vhdl program to see what it is doing.

I made some progress by using the xc3sprog "-I" option. The first (xc3sprog) design is definitely helping the Flash memory to be detected!

I'm not sure what the "ISF Bitfile" is.

xc3sprog -c jtaghs1_fast -I design.bit 
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 774 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
	http://sourceforge.net/mail/?group_id=170565 
Check Sourceforge for updates:
	http://sourceforge.net/projects/xc3sprog/develop

Using Libftdi, 
JEDEC: 20 ba 0x16 0x10
Found Numonyx N25Q Device, Device ID 0xba16
Unexpected N25Q size ID 0x16
ISF Bitfile probably not loaded

I have tried writing bit, mcs and hex files (converted using Vivado) but here is the result that I get:

xc3sprog -c jtaghs1_fast -I design.hex:w:0:MCS
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 774 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
	http://sourceforge.net/mail/?group_id=170565 
Check Sourceforge for updates:
	http://sourceforge.net/projects/xc3sprog/develop

Using Libftdi, 
JEDEC: 20 ba 0x16 0x10
Found Numonyx N25Q Device, Device ID 0xba16
Unexpected N25Q size ID 0x16
ISF Bitfile probably not loaded

I found this webpage which completely describes my situation... the Unexpected N25Q size ID 0x16, but their solution does not look applicable to me. The memory size should be 4MB.

sourceforge xc3sprog to N25Q flash memory

Edited February 17, 2021 by charkster

[xc6lx45]

I haven't studied the code but I suspect you have to add the 0x16 size ID (e.g. from datasheet, see the format of other entries).

Actually I'd check first that all the other bytes (after JEDEC) match the identity of the flash chip (see datasheet, search again for JEDEC). If yes, your programming bitstream is working correctly (and probably it does already now, but the specific device isn't supported yet). 

[charkster]

I did find the page which describes the approach that @xc6lx45 suggested.

https://www.eevblog.com/forum/microcontrollers/alinx-ax309/

I found the Micron datasheet for the specific flash memory:

https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_32mb_3v_65nm.pdf?rev=27fc6016fc5249adb4bb8f221e72b395

I searched for "JEDEC", but could not see any thing that relates to "20 ba" hex.

@xc6lx45 you were right about the need to modify xc3sprog source code to get this memory supported.

Thanks for all your help... I will pick up this effort at a future date. Just being able to program the FPGA is good for now.

Edited February 17, 2021 by charkster

[xc6lx45]

I dimly recall the process ... it's been a while ago... yes I think you can do the two steps separately from the command line (first upload the bridge .bit file, then do flash operations).

But when you get the readout of the flash ID bytes, that part seems to be working already (it can be also done in a single command).

And, spartan 6 / 7 are very similar if not identical as far as xc3sprog is concerned.

Edited February 17, 2021 by xc6lx45

[charkster]

I was able to program the spi flash memory on the cmod a7 by compiling xc3sprog from source on my raspberry pi. Here are the steps I used:

(1) install libftd2xx drivers
download libftd2xx-arm-v7-hf-1.4.22.gz and follow instructions in ReadMe.txt

(2) Download xc3sprog from github
sudo apt update
sudo apt install build-essential libusb-dev libftdi-dev libgpiod-dev wiringpi git cmake
git clone https://github.com/matrix-io/xc3sprog

(3) Modify progalgspiflash.cpp
add case 0x16:

     case 0xba:
        fprintf(stderr, "Found Numonyx N25Q Device, Device ID 0x%02x%02x\n",
                fbuf[1], fbuf[2]);
        switch (fbuf[2])
          {
          case 0x16:
            pages = 16384;
            sector_size = 65536;
            break;

(4) Compile xc3sprog
mkdir xc3sprog/build
cd xc3sprog/build
cmake ..
make
sudo make install

(5) Run the program command with the "-I" option, using the attached first.bit to help detect the spi flash rom.

xc3sprog -c jtaghs1_fast -Ifirst.bit

xc3sprog -c jtaghs1_fast -I your_design.bit

 

Works like a charm.

I have attached the xc3sprog compiled to run on raspberry pi (it still needs the libftdi1 library to be installed... sudo apt-get install libftdi1).

first.bit run_first_spi_flash_cmod_a7.sh xc3sprog

The first.bit file was created by taking this VHDL design from the github xc3sprog repo: xc3sprog/bscan_spi/bscan_xc7_spi.vhd and making it into a bit file using Vivado (with the target being the CMOD A7 board). I have included the constrants file "constr.xdc" which I used to create the first.bit file.

 

constr.xdc

Edited July 18, 2021 by charkster
additional info added

[Brent Gardner]

Brilliant, @charkster!  I was able to get it to work on a Raspberry Pi as well as 64-bit Ubuntu.  To further assist others, here are some additional notes:

The CmodA7 does not need them, but the latest FTD2XX drivers are available from https://ftdichip.com/drivers/d2xx-drivers/.  If you don't need them, replace "cmake .." with "cmake -DUSE_FTD2XX=OFF .." when compiling xc3sprog.  I couldn't get them to install properly on a Pi.  Select the appropriate archive for your architecture and extract:

tar -xfv libftd2xx-[architecture]-[version].gz

You may need the "z" flag as well, as it seems that FTDI mixed up their file extensions, and the downloads may be an uncompressed tarball.  Follow the instructions in the extracted release/ReadMe.txt file to install the FTD2XX libraries.

When compiling xc3sprog on a non-Raspberry Pi, replace "cmake .." with "cmake -DUSE_WIRINGPI=OFF ..".

I had some issues with my USB connections during programming, either read/write errors, timeouts, or disconnections, especially on the Pi.  Using compressed bitstreams seemed to help, as well as using "jtaghs1" instead of "jtaghs1_fast".  I'm not sure if this has anything to do with the relatively high 66MHz CCLK set in constr.xdc.  Running with the verbose flag helps identify these issues, so I recommend the one-liner:

xc3sprog -v -c jtaghs1_fast -Ifirst.bit your_design.bit

Note that first.bit leaves the blue LED turned on, and the change in red LED state is only in brightness due to the high rate of change.  The CmodA7 requires a power cycle to load the program from SPI flash.

 

[Brent Gardner]

Forget all that.  openFPGALoader (https://github.com/trabucayre/openFPGALoader) is ready as-is (after compiling/installing), with no need to compile first.bit.  It also automatically resets the device (loads program from SPI flash).  For the CmodA7:

openFPGALoader -c digilent --fpga-part xc7a35tcpg236 -f your_design.bit