Tim S.

Hi @vttay03, @jpeyron, I may have a solution to this problem for you. I am working with a Arty A7-100T; and I am designing material that mostly does not make use of a Microblaze / AXI setup. From a different tutorial, I learned that this board should be configured to operate the boot-up at 33 MHz instead of the default of 3 MHz. Also, the configuration modes should be both JTAG and Master-SPI-x4 selected for the bitstream configuration. By default, a new project in Vivado 2019.1 with the Arty-A7-100 boad selects only configuration of JTAG and no configuration is selected for Flash memory. These options can be found under Open Implemented Design | Tools | Edit Device Properties... Note that I've noticed that the Arty A7-100T may have a power-on failure where the board only operates correctly if PROG_B is pressed once after adding power by plugging-in USB-A port. Tim S.

Thanks, @JColvin, I have a few additional questions. The schematic shows IC1 as part N25Q512A836SF40G . I was unable to find this exact part on DigiKey, though there are similar part numbers. Also, the reference manual lists an older and smaller flash part, the N25Q256A. Can you clarify? The part is now populated with the larger and newer part due to sourcing supply and demand? Also, the part number or serial on the IC is: 7JD1 7ZAI5 RW243 with logo ISA . Can you clarify if this is a generic N25Q256 or N25Q512 ? Tim

Hi. I work with FPGAs and other embedded systems for a living. I am going through self-directed learning on the Zybo-Z7 and the Arty-A7, with FPGA design textbooks. The Analog Discovery 2 has been a great help with this; and I have authored a few custom Pmod drivers direct in the FPGA logic that do not require a processor system with AXI. One project I authored as a fun experiment for the Arty-A7 was to drive both text on the Pmod OLEDrgb and a PWM mix duty cycle on the 4 discrete RGB LEDs with custom 24-bit RGB color mixing values to compare PWM scaling of the discrete RGB against the 16-bit color of the Pmod OLEDrgb. I have achieved numerous color blends on the discrete RGB LEDs. Tim

I purchased a Pmod SF3. The Reference Manual and the anti-static packaging document Pins 7, 8, as No Connect. The Schematic documents Pin 7 as No Connect and Pin 8 as Flash Chip Reset signal. Can someone clarify the discrepancy? Tim

I am using the PMOD CLS to develop a custom CLS driver via the SPI interface. The PMOD CLS data sheet did not define the protocol, so I used the Analog Discovery 2 to watch the SPI traffic of the Digilent PMOD CLS driver in a Microblaze architecture on a Arty A7-100T board. The FPGA signals are SS, MOSI, MISO, SCK. For my design, MISO is an input that is optimized away for lack of logic connection. The SS, SCK, and MOSI are operated the same as the C api calls from the PMOD CLS BSP driver. With the Digilent driver, I can control the two lines of text to display any text. With my own driver, I believe the only issue is that their are several nanosecond duration spikes on the SS signal during a data transfer. This interferes with the escaped commands ESC]digit;digitdigitCMD as well as the text data. The spikes appear random: SS is held low and for nanoseconds the SS may rise to a value of '1'. Note that I am driving the PMOD CLS via JB of the Arty A7-100T. The jack JB is a high-performance port. I am running the SCK at 625 kHz. Has anyone seen spikes like this before on the SS and found a solution? Thanks.

Hi @jpeyron, Regarding your question on the KYPD: with the clock wizard set as discussed, the MIG UI clock is 86 MHz. If I use the KYPD driver as-is, the GPIO will poll at a frequency based on the CPU clock of the Microblaze. This caused some keys to not be read, or to be read as multiple keys pressed. Only about 1/2 of the keys would detect properly. To solve this, I added a micro sleep call to allow the GPIO of the KYPD columns to settle before polling the rows. With this modification, all of the keys detect correctly using the demo code. u16 KYPD_getKeyStates(PmodKYPD *InstancePtr) { u32 rows, cols; u16 keystate; u16 shift[4] = {0, 0, 0, 0}; // Test each column combination, this will help to detect when multiple keys // in the same row are pressed. for (cols = 0; cols < 16; cols++) { KYPD_setCols(InstancePtr, cols); usleep(5); rows = KYPD_getRows(InstancePtr); // Group bits from each individual row shift[0] = (shift[0] << 1) | (rows & 0x1); shift[1] = (shift[1] << 1) | (rows & 0x2) >> 1; shift[2] = (shift[2] << 1) | (rows & 0x4) >> 2; shift[3] = (shift[3] << 1) | (rows & 0x8) >> 3; } // Translate shift patterns for each row into button presses. keystate = 0; keystate |= KYPD_lookupShiftPattern(shift[0]); keystate |= KYPD_lookupShiftPattern(shift[1]) << 4; keystate |= KYPD_lookupShiftPattern(shift[2]) << 8; keystate |= KYPD_lookupShiftPattern(shift[3]) << 12; return keystate; } Thanks, Tim

Just to make sure my explanation is thorough. The above has a typo. It should read: Linux has a case-sensitive file system whereas Windows has a case-insensitive file system.

Hi @jpeyron, The following solved the missing xspi. 1. Rename pmodOLEDrgb to PmodOLEDrgb under Vivado-library . 2. Add the PmodOLEDrgb IP to the block design. 3. Open the IP in IP Packager. 4. Under File Groups, rename the path driver/pmodOLEDrgb for the xspi to have capital 'P' for Pmod instead of lowercase, for each file. 4. Retarget the IP submodules to Arty A7 100. 5. Regenerate the IP module in the IP packager editor. 6. Close the subproject that opened for PmodOLEDrgb. 7. Remove the IP from the block design. 8. Delete the hardware description from project and file system in the SDK. 9 Re-add the PmodOLEDrgb to the block design, and then Regenerate top design bitstream. 10 Export hardware with bitstream to SDK. 11. Open in SDK from Vivado menu. Best, Tim

Hi @jpeyron, I have a successful design with KYPD and OLEDrgb. The only bug is the ABCD column of the keypad indicates multiple key press and the correct key, at the same time. Thank you for your assistance. Best regards, Tim

Hi @jpeyron, I discovered why the xspi sources are missing. Linux has a case-sensitive file system whereas Windows has a case-sensitive file system. The packaging of the PmodOLEDrgb has mixed folder name alphabet-case of the first character 'p' in the folders PmodOLEDrgb. This causes silent errors on Linux whereas I presume there would be no error on Windows. Best, Tim

Hi @jpeyron, I previously copied the Vivado board files under 2019.1/data/boards/board_files for both the /opt/Xilinx/Vivado/ and /opt/Xilinx/SDK/ directories on Linux. I have had problems with the Vivado_Init.tcl approach where Vivado was inconsistent in finding the additional boards. See this Digilent tutorial. I modified the mig,prj to use the correct 100T (as opposed to 35T) part. Also, the PMOD IP from vivado-library was originally targeted to the classic Arty board. To solve this, I opened the two PMOD in IP Packager and retargeted the IP submodules to Arty A7 100. I noticed that the OLEDRGB PMOD contained the xspi sources in the IP packaging. The system.hdf says as shown in the screenshot. It has the FPGA part selected without the board, as you noticed. With the OLEDrgb removed from the project and only kypd preset, the Microblaze project does execute over JTAG as expected. After adding OLEDrgb, the xspi sources are missing, so the project cannot compile. What option did you select to export the Vivado hardware to the SDK? I use File | Export | Hardware , and I include the bitstream. I select Local to Project. My clocking wizard configuration is the same as your screenshots. Tim

Hi @jpeyron, I switched to the Arty A7-100T. I have imported the latest master git branch of the Digilent vivado-library for use in Vivado 2019.1 . The same missing files compilation error exists. See a screenshot below. Regards, Tim

I am trying to design a PL block design and SDK application to exercise the Pmod KYPD and Pmod OLEDrgb together with Vivado 2019.1 . I downloaded the Vivado-library git release for Vivado 2019.1 . In the SDK, I notice that driver PmodOLEDrgb.h is missing source files xspi.h and xspi_l.h . Where do these sources come from? Tim S.

Hi @jpeyron, The base-linux project provides a complex and highly configurable IP Core for the MIPI RX as part of the Board Design. The core is not included under repo/ of the design. It cannot be customized without a license. And it cannot be synthesized without a license. The name of the MIPI RX also differs from the simpler model of the PCam 5 demo. The demo provides MIPI_CSI_2_RX_0 which is an instance of "MIPI CSI-2 Receiver v1.1". The linux base utilizes an absent mipi_csi2_rx_subsystem_0 which is an instance of "MIPI CSI-2 Rx Subsystem v1.0" containing unlicensed core "MIPI CSI-2 Rx Controller v3.0" (Product Guide 232?). Regards, Tim

Specifically, I am using the WebPACK without the SDSoC voucher.