aytli

Members
  • Content Count

    15
  • Joined

  • Last visited

About aytli

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. aytli

    Zybo HDMI startup issues

    Thanks for the response, is there something I can probe on the board to see if it's being back powered or not?
  2. aytli

    Zybo HDMI startup issues

    So I understand that the HDMI ports on the Zybo should be disconnected on startup, due to some power reflection issue. Does this problem also exist in other Digilent boards that can handle HDMI? I'm currently looking at Pynq, Arty-A7, and Nexys Video. Alternatively, if I were to somehow route a video input into the Zynq board through the 15-pin PCAM port (either from a camera or an HDMI-CSI adapter), would it have the same issue?
  3. I'm working with a computer that has a DVI video port, which I want to route into the HDMI sink of my Zybo Z7-10. I've tried using a passive splitter (DVI to DVI+HDMI) to capture the video signal going to the monitor, as a DVI to HDMI adapter to directly feed the video signal into my board. When I connect either of these to the HDMI sink, the DONE LED (LD12) on my board will light up (it looks dim, and it gets dimmer when I use the adapter instead of the splitter). This will happen even when I flip the power switch off and unplug everything including the power cable. Nothing else on the board seems to be powered. Here are the two connection configurations I mentioned above: Computer (DVI) --> Splitter -----> Monitor (DVI) \\ ---> FPGA (HDMI) and Computer (DVI) --> Adapter --> FPGA (HDMI) The board is still fully functional, and this effect doesn't seem to happen with any other video source. I'm looking at the schematic for this board and there appears to be no connection between the HDMI sink plug and the power rail. What could be causing this issue?
  4. I'm working on an HDMI processor using a Zybo Z7-20 board, with Vivado 2016.4. The starting point of this project was the HDMI demo project, using the dvi2rgb and rgb2dvi cores. Since the dvi2rgb block doesn't handle audio data, we've connected a commercially available HDMI audio extractor right before the HDMI RX port. I'm using 3 different video sources: laptop, ipod, and ipad (with lightning to HDMI dongle). All 3 are compatible with the FPGA, I've fed them each directly into the RX port and displayed them to a monitor on the TX plug. They're also compatible with the audio extractor, I've fed them through the audio extractor and directly to a monitor. But when I combine the audio extractor with the FPGA, it either extracts audio, or it passes video, but not both at the same time. I suspect that the EDID of the dvi2rgb block is causing some issues, so I've been modifying the settings, but I can't seem to find a setting that allows the audio extractor to both extract sound and pass the video stream. Here are some of the things I've done to the EDID: - Padded the default 128 byte EDID with 128 more bytes, then edited dvi2rgb.vhd to use 8 bits for the EEPROM address - Enabled the CEA extension block, and enabled/disabled the basic audio setting - Used an exact copy of the 128 byte EDID of my external monitor, with and without 128 bytes of padding What are some other things that I can try? Besides the EDID, what else can be causing this issue?
  5. Hi @jpeyron I've probed those components and got the following voltages: C222 - 5V across, I'm assuming this is the 0805 part. There's a smaller 0603 part beside it that measures 8V on one end and 3V on the other. C223 - 3.3V C229 - 3.3V C233 - 1.8V C237 - 5V C240 - 1.8V I have tried a different cable, which doesn't work. We don't have another computer with Vivado installed. Adept 2 is able to see the board, and my computer does actually think that a device is connected. When I start the hardware server in Vivado, I get the following error message: open_hw_target INFO: [Labtoolstcl 44-466] Opening hw_target localhost:3121/xilinx_tcf/Digilent/210351A6AF38A ERROR: [Labtools 27-2269] No devices detected on target localhost:3121/xilinx_tcf/Digilent/210351A6AF38A. Check cable connectivity and that the target board is powered up then use the disconnect_hw_server and connect_hw_server to re-register this hardware target. ERROR: [Common 17-39] 'open_hw_target' failed due to earlier errors.
  6. I can no longer connect to my Zybo Z7-10. About an hour ago I tried to load a project on Vivado SDK, and it wasn't able to connect to the board. I restarted SDK, power cycled the board a few times, reconnected the usb cable, and also restarted my computer, and it still wasn't able to connect. I then tried using the hardware manager in Vivado to auto connect to it, and it didn't work. I've tried powering it with both the usb cable and a 5V wall adapter. I've tested the wall adapter and it's working fine. After I gave up on connecting to it, I tried to run the demo project by switching the programming jumper to the QPSI position. The demo project didn't run, but I noticed that the red LED (PGOOD) was a little dimmer. Every time I powered up the board I can very clearly see that the red LED was getting weaker and weaker. As I'm writing this post, the LED is pretty much off (I can barely see a faint glow when I cup my hands over it). The LED is not entirely dead, when I use my multimeter to test continuity, the LED blinks briefly when I probe it. I didn't see or smell any smoke, and none of the large components felt warm when I powered up the board. I don't see any burn marks or cold joints on the board. I've probed the 5V rail, it is getting power from the wall adapter and it isn't shorted to ground. This board was working fine an hour ago. The last project I compiled was an HDMI processor with a sink and source. Did I accidentally burn my board? This board is just over 3 months old, is it covered by some kind of warranty? EDIT: Probing that red LED gives me 3.3V on one end and about 1.7V on the other.
  7. // Dimensions of the digit images #define IMG_WIDTH 74 // MUST BE A MULTIPLE OF 2, max 128 #define IMG_HEIGHT 86 #define IMG_SIZE_PIXELS IMG_WIDTH*IMG_HEIGHT*4
  8. Short version: I have reason to believe that my RAM isn't clearing on startup. It seems to retain its old value even when I reset, reprogram, or power cycle my board. I'm also having trouble writing data to arrays. I'm working on an HDMI processor with a Zybo Z7-10 board, and I'm trying to overlay some images on my HDMI output. The images are read from an sd card on startup, and stored in the following array, where IMG_SIZE_PIXELS is 74*86*4. static uint8_t digits[10][IMG_SIZE_PIXELS] __attribute__((aligned(0x20))); My block diagram has a video mixer core connected between the video dma and the video output. I can write images to the layers inside the video mixer, and then enable/disable the layers to show/hide the images. This configuration worked, I was able to load my images from the sd card, display them on the output screen (below), and even change it on the fly. I then declared a new array and initialized it by looping through every element and setting it to 0. I then wrote it to one of my video layers. static uint8_t asdf[IMG_SIZE_PIXELS] __attribute__((aligned(0x20))); for (i = 0; i < IMG_SIZE_PIXELS; i += 4) { asdf[i + 0] = 0; asdf[i + 1] = 0; asdf[i + 2] = 0; asdf[i + 3] = 0; } The resulting image (below) is a noisy version of the original image, loaded from the sd card. Even when i completely disabled the sd card code, physically removed the sd card, and even power cycled the board, I can still see the old image. I expect to see a black block, since I set all the elements of the array to 0. According to the debugger, every element of this array was indeed set to 0. It seems like the old image data was written to some form of non volatile memory. When I try running the code what reads the images from the sd card and outputs it to the screen, it seems to work fine. If I disable that code and write my own array that I've initialized to all zeros, it still outputs the old image. One thing I should mention is that I've greatly increased the size of my stack and heap to 0xFFFFF and 0xFFFF respectively. Although the stack and heap both live in RAM, and shouldn't write to any form of non volatile memory.
  9. aytli

    Zybo Z7-10 audio passthrough

    Hi @jpeyron The DMA audio demo uses the d_axi_i2s_audio IP core, which has a S2MM output and MM2S input. The first thing I've tried was to route the output directly into the input, which didn't work. In addition, the way the C code handles recording is by configuring the DMA block to record, then telling the i2s core to store N bytes from the input into a register. The HDMI demo works by reading video data into a series of video buffers, and displaying image data from a series of frame buffers. I can make an HDMI passthrough by pointing the display output buffer to the video input buffer. I'm wondering if there's a similar solution for audio. I've had some trouble getting that instructables project to work. The i2s controller looks fine, but the SerialEffects block doesn't seem to match the block diagram (which is really blurry). I'll try it again and see if I missed something. Does that d_axi_i2s_audio IP core have any documentation?
  10. Hello, I'm working on an audio project with a Zybo Z7-10 board (with Vivado 2016.4), and as a starting point I'm trying to set it up as an audio passthrough. I've been working off of the DMA audio demo, but I can't seem to get it to output a continuous stream. Is there a way to modify it so that the sound input can be immediately routed to the output without having to record it first?
  11. Hi @jpeyron, EDIT: I just tried programming another board (also zybo z7-10), and it worked. Maybe there was a problem connecting to my original board that caused this issue. I've installed Vivado 2016.4, and I was able to get a bitstream for the HDMI demo in under 30 minutes. I'm able to program the FPGA, but I'm having trouble programming the ARM core. When I try to run the debugger, I get one of the following errors, none of which I can consistently recreate: Memory write error at 0xF8000118. Cannot flush JTAG server queue. FT_Read returned 0, expected 12 Memory read error at 0xF8000108. Cannot flush JTAG server queue. FT_Write failed: io error Memory write error, cannot access DAP, invalid ACK value I've looked at the memory map generated by the linker (lscript.ld), and those addresses don't seem to be in any of the memory regions. Here's a picture of the memory map: On an unrelated note, the Zybo Z7-10 audio DMA demo also doesn't work properly on Vivado 2017.3. It compiles relatively fast, and I'm able to load both the bitstream and C code, but it has issues running with the demo code. I was able to use Vivado 2016.4 to generate a usable bitstream.
  12. Hi Jon, Thanks for the help, my laptop has an i7-7500U with 12GB of RAM, 2 cores at 2.7GHz. I only had one project running on Vivado. Is there a reason why the bitstream takes that much longer in the newer version of Vivado? The 1h generation time I got last night is usable, but obviously faster is better.
  13. Hi Jon, Thanks for the response, I checked the version number in system_bd.tcl and it was already set to 2017.3, I haven't had to change it. I was actually able to get the project to compile this morning, shortly after I posted my question and before you responded. It took about 3 hours to generate a bitstream, but it and the demo code both worked. Right now I'm compiling the same block diagram again, just to see if Vivado always takes this long, and it seems to be hanging again. Looking at the properties of the route_design step, it seems to get stuck at 75% for a very long time. Is there anything I can do to get Vivado's compile time down to something more reasonable, maybe under 30 minutes? I've been able to compile the HDMI-in demo for the older Zybo and it didn't take nearly as long. EDIT: Second compile took about an hour, which is much better.
  14. I've been trying to get the Zybo Z7-10 HDMI demo (link) to run on my board, but I can't seem to be able to compile the actual project (using Vivado 2017.3 on Windows 10). I created the project from the create_project.tcl script in the proj folder, and was able to generate the block diagram and wrapper. I upgraded the IP cores and verified that the xdc file was consistent with the wrapper. But when I try to generate a bistream, Vivado always seems to get stuck on route_design. I've left Vivado running for 4 hours and it still can't move past route_design, despite it still using ~30% of my CPU. From these two forum posts, could it be a version problem? I don't seem to have a system.tcl file in my project. I've been able to run the demo on my board by loading the provided bitstream and running the example code, but I would like to modify the demo and use it as a starting point for my project.
  15. I'm working with the HDMI ports on a Zybo Z7-10 development board, and I'm trying to set it up as an HDMI passthrough. As in, the HDMI input signal would simply be fed into the HDMI output port without any processing in between. I will eventually be filtering the video signal but I'm using this passthrough as a starting point. The HDMI hardware on my Zybo, as well as my HDMI source and output screen, are all confirmed working because I've been able to run Digilent's HDMI demo on it. I'm using Vivado 2017.3 I was able to get my block design started by following this forum post, replacing the VGA output with an HDMI output. I can currently feed my input video signal to my HDMI output. However, my output video quality looks horrible. I'm currently using a laptop as my HDMI source, and a custom built screen as my video output. This album shows pictures of my video output. The output of the color gradient contains a lot of vertical lines, and the color transitions are not smooth. The color bar also contains the same vertical lines, although not as visible. For the most part the colors on the output screen match the colors of the original image. I've also tried displaying a vertical color gradient, and same vertical lines appear, as well as a bunch of horizontal lines. Attached is a picture of my current block diagram. The DDC pins are connected to scl and sdi of the hdmi rx port. The output of the clocking wizard is 200MHz. GND and VDD are constant blocks of value 0 and 1 respectively. The system clock is configured as follows: set_property -dict { PACKAGE_PIN K17 IOSTANDARD LVCMOS33 } [get_ports { clk }]; #IO_L12P_T1_MRCC_35 Sch=sysclk create_clock -add -name sys_clk_pin -period 8.00 -waveform {0 4} [get_ports { clk }]; I suspect it might be a clocking issue, but I'm not sure which clock signal to alter, and what frequency to set it to. Let me know if I can provide any additional information.