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


Forums

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

Calendars

  • Community Calendar

Found 5 results

  1. 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
  2. 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.
  3. Blink CMOD-A7 LED withOUT Pmod IPs

    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
  4. 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" (http://www.digikey.com/products/en/integrated-circuits-ics/memory/774?k=hyperram&k=&pkeyword=hyperram&pv142=133&FV=ffe00306%2C1c0011&mnonly=0&newproducts=0&ColumnSort=0&page=1&stock=1&quantity=0&ptm=0&fid=0&pageSize=25) is like a combination between DDR and SRAM, this blog post describes quite nicely (with later posts showing implementation): https://warmcat.com/embedded/hardware/hyperbus/2016/09/02/hyperram.html 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!
  5. 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. https://reference.digilentinc.com/learn/programmable-logic/tutorials/htsspisf/start 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!