Search the Community

Showing results for tags 'cmod-a7'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • News
    • New Users Introduction
    • Announcements
  • Digilent Technical Forums
    • FPGA
    • Digilent Microcontroller Boards
    • Non-Digilent Microcontrollers
    • Add-on Boards
    • Scopes & Instruments and the WaveForms software
    • LabVIEW
    • FRC
    • Other
  • General Discussion
    • Project Vault
    • Learn
    • Suggestions & Feedback
    • Buy, Sell, Trade
    • Sales Questions
    • Off Topic
    • Educators
    • Technical Based Off-Topic Discussions


  • Community Calendar

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 9 results

  1. This issue had been a pain ever since I started using the CMDO-A7 devices. In Windows 7, using Vivado 2016.2, if I open the hardware manager in Vivado to configure the device, after a few minutes Vivado decides that the target is no longer available and disconnects it. This is a particular problem when I am also using the USB UART... though the problem doesn't happen immediately. This issue makes using the ILA extremely difficult to impossible with this board. When I use the Adept Utility for Windows to configure the board I can use the UART all day without a problem. I suspect a JTAG/UART driver related issue is to blame.
  2. Hello, I recently purchased a Cmod A7-35T kit and its USB connection is so unstable that it renders the device almost unusable. I've tried every combination of 2 different host machines (including a laptop running on battery power to rule out a noisy power outlet as a potential cause) and 4 different micro-USB cables but to no avail. I've had somewhat more luck with the shortest USB cable as I was finally able to upload a design and test it after fighting against intermittent disconnections for a few hours. While using the hardware manager in Vivado, I can see the A7-35T appear and disappear about every 5-10 secs. Every time it disappears, the following error messages are logged: But these connectivity issues aren't limited to Vivado. I can see the same thing happening in the dmesg log while Vivado is not even running. I've browsed the forum a bit before posting this and noticed that a few people have experienced issues similar to mine with the Cmod A7. It has been suggested that using higher quality USB cables can prevent intermittent disconnections but I'd expect at least one of the 4 cables I tested it with to be of adequate quality. I've used the same cables with other dev kits in the past and never experienced such problems. I was wondering if a definitive fix has been identified (such as a specific USB cable you can recommend me) or if my board is simply defective. Thank you, PM
  3. I am interested in buying Spartan-7 FPGA Module: but first I would like to know if it suffers same USB cable issue as CMOD-A7: Since FTDI circuitries look similar on these two boards I just want to make sure the faulty design was not copied over from A7 onto S7.
  4. Hi all, i did the tutorial "How To Store Your SDK Project in SPI Flash" ( and everything works fine. ...But now i recognise when, i connect the Cmod-A7 to my USB-port, the FPGA is programmed but the bootloader does not start the C-programm i created in the SDK. If i now disconnect and connect it again, the bootloader starts the C-programm and everything works fine. Maybe someone know how to handle this?
  5. So my current project is very simple, but I've yet to settle on how the control logic is going to be implemented. I think the FSM and Microblaze are both perfectly viable solutions, but I want to find the intersection of maximum learning and minimum complexity. The controller will be performing three tasks: -Pass alternating I and Q data from another module via usb to the user. -Receive data from the user via usb to set a desired frequency. -Interface with the clocking manager to request the new frequency. I am sure I could create an FSM to accomplish this, the USB controller has already been done, my hesitation is a lack of understanding of the AXI4 and DRP interfaces. I am familiar with 8-bit RISC AVR microcontroller, and if given a similar structure, I would think designing with a microcontroller would be almost trivial, but there is surely a learning curve to climb. The question boils down in my mind to a balance between the complexity of the FSM and the learning curve of Microblaze. I also am inclined to say some introductory experience with Mircroblaze would likely be desirable for a future employer. What do you think would be a better opportunity for learning?
  6. smarano

    eFuse Programming

    Hi I'm tring to program my cmod a7 35T Digilent board with an encrypted bitstream. I read that to do this i need to program the eFuse register with a key.nky file, but when i try to do this i found a problem. This board don't have a jtag connector but it can be programmed via usb. When i try to program efuse a found a problem "cannot program efuse register with this cable". Anyone can tell me if there is another way to program efuse or if this board can't support encryption bitstream? regards Stefano
  7. Hello, I created a block diagram that has a axi_gpio_0 block, as you can see in my image. Below is most of my constraint file. My diagram synthesizes, implements and generates a bitstream. I was able to get into SDK with no problems. I am stuck in SDK now. Goal: I am just trying to blink an LED (gpio_io_o[4]) using one of the the example code projects shown in system.mss file. I chose the "xgpio_example.c"; first on the list. The example code has these lines: #define LED 0x01 and #define LED_CHANNEL 1. This code should just simply blink an LED. I am not sure if LED_CHANNEL is channel "1", or what "LED_CHANNEL" means in the code. Using these original settings my LED did not blink or light up at all. Looking at my constraint file, you will see that I am using gpio_io_o[4] and gpio_io_o[5] for my LEDs, so I changed the first line to #define LED 0x04. This had no effect. I tried everything I could think of. For example, I tried making a change like this: #define LED_CHANNEL 4, but this had no effect. I tried many combinations of things. Using the oscilloscope, I looked at all of the pins on the PMOD connector, but nothing is active. I'm sure I programmed the FPGA and code correctly since the processes went smoothly. I'm trying to avoid using any IP blocks other than the built in axi_gpio blocks. Those IP blocks from example code do not TEACH us anything and are rather useless in that regard. I've looked all over, but cannot find a working version of "BLINKY" code (which is fairly standard in MCU and Microprocessor examples). Can someone please point out a decent GPIO tutorial that actually works? Here is a sample of the code: XGpio_SetDataDirection(&Gpio, LED_CHANNEL, ~LED); The "LED_CHANNEL" AND ~LED parameters are confusing. Why is LED inverted? For example, if LED = 0x01, then ~LED = 0xfffffffe. Why? Thank you, Richard V My constraint file: # LEDs set_property -dict { PACKAGE_PIN A17 IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o[4] }]; #led[0] }]; #IO_L12N_T1_MRCC_16 Sch=led[1] set_property -dict { PACKAGE_PIN C16 IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o[5] }]; #led[1] }]; #IO_L13P_T2_MRCC_16 Sch=led[2] Here are my other GPIO bits: #OLED set_property -dict { PACKAGE_PIN G17 IOSTANDARD LVCMOS33 } [get_ports { spi_0_ss_io[0] }]; #CS #IO_L5N_T0_D07_14 Sch=ja[1] set_property -dict { PACKAGE_PIN G19 IOSTANDARD LVCMOS33 } [get_ports { spi_0_io0_io }]; #MOSI #IO_L4N_T0_D05_14 Sch=ja[2] set_property -dict { PACKAGE_PIN N18 IOSTANDARD LVCMOS33 } [get_ports { spi_0_io1_io }]; #MISO #IO_L9P_T1_DQS_14 Sch=ja[3] set_property -dict { PACKAGE_PIN L18 IOSTANDARD LVCMOS33 } [get_ports { spi_0_sck_io }]; #SCK #IO_L8P_T1_D11_14 Sch=ja[4] set_property -dict { PACKAGE_PIN H17 IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o[0] }]; #DC #IO_L5P_T0_D06_14 Sch=ja[7] set_property -dict { PACKAGE_PIN H19 IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o[1] }]; #RES #IO_L4P_T0_D04_14 Sch=ja[8] set_property -dict { PACKAGE_PIN J19 IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o[2] }]; #VBAT #IO_L6N_T0_D08_VREF_14 Sch=ja[9] set_property -dict { PACKAGE_PIN K18 IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o[3] }]; #VDDC #IO_L8N_T1_D12_14 Sch=ja[10] This is an excerpt from the example code and was generated by SDK: #include "xparameters.h" #include "xgpio.h" /************************** Constant Definitions *****************************/ #define LED 0x01 /* Assumes bit 0 of GPIO is connected to an LED */ /* The following constants map to the XPAR parameters created in the * xparameters.h file. They are defined here such that a user can easily * change all the needed parameters in one place. */ #define GPIO_EXAMPLE_DEVICE_ID XPAR_GPIO_0_DEVICE_ID /* * The following constant is used to wait after an LED is turned on to make * sure that it is visible to the human eye. This constant might need to be * tuned for faster or slower processor speeds. */ #define LED_DELAY 1000000 /* * The following constant is used to determine which channel of the GPIO is * used for the LED if there are 2 channels supported. */ #define LED_CHANNEL 1 /**************************** Type Definitions *******************************/ * The purpose of this function is to illustrate how to use the GPIO * driver to turn on and off an LED.* * @param None ** @return XST_FAILURE to indicate that the GPIO Initialization had * failed. ** @note This function will not return if the test is running. * ******************************************************************************/ int main(void) { u32 Data; int Status; volatile int Delay; /* Initialize the GPIO driver */ Status = XGpio_Initialize(&Gpio, GPIO_EXAMPLE_DEVICE_ID); if (Status != XST_SUCCESS) { return XST_FAILURE; } /* Set the direction for all signals as inputs except the LED output */ XGpio_SetDataDirection(&Gpio, LED_CHANNEL, ~LED); design_spi_oled.pdf
  8. Hi all and Digilent representatives! I am a "long" user of the Cmod A7 and am quite pleased with it, except for the choice of SRAM. And on the side I have been playing with another RAM that is easy to use, delivers better performance (about 200 MB/s for the 3.3v version), and more space (8Mbyes) which would be a really nice update to the Cmod-A7. The new "HyperRAM" ( is like a combination between DDR and SRAM, this blog post describes quite nicely (with later posts showing implementation): What is Digilent's view/thoughts on the usage of HyperRAM instead of the (aging) SRAM? A quick check seems to suggest that it is about half the price of the SRAM currently used as well. I hope for a fruitful discussion. Best regards!
  9. Hello, I am following this guide to program the spi flash on the Cmod-A7 so that it can boot from spi flash and run the program in the ddr. However, after flashing both parts, the bootloader is able to run but it only outputs infinite "Bootloader: Processed (0x)0000022a S-records" and my program won't run. Thanks and best regards!