AndrewHolzer

Technical Forum Moderator
  • Content count

    94
  • Joined

  • Last visited

  • Days Won

    4

AndrewHolzer last won the day on February 1

AndrewHolzer had the most liked content!

2 Followers

About AndrewHolzer

  • Rank
    Frequent Visitor

Profile Information

  • Gender
    Male
  1. Hi @mihai5, If you are up to date with your tools, then you should check <dir-of-your-project>/images/linux. The link that you provided says that the files you are looking for are found in the /tftpboot directory as well as this images/linux directory. These are just copies of each other. If it isn't important that you find the files you are looking for in /tftpboot, then you should look in the <dir-of-your-project>/images/linux directory. AndrewHolzer
  2. Hi BeamPower, I've worked on the project you are trying to use. The error you are seeing arises because the clk_wiz IP block is outdated and needs to be upgraded. Thankfully this is easy to do within Vivado. What you need to do is open up the GPIO project, and underneath tools git Report>Report IP Status. This will open a new tab at the bottom of your screen that shows any IP that is being used by the design. The status for the clk_wiz should say that it needs to be upgraded, so check the box next to clk_wiz, and then Upgrade Selected should become active. Click that, and if you see a confirmation that asks you to use Core Containers, make sure you select that option that doesn't use them. After that, you should be asked if you want to generate new output products, and you can do so. Once that is completed, give a shot at generating the bitstream. I've updated the online repositories to contain the updated clk_wiz ip cores. Let me know how everything works out for you! Regards, AndrewHolzer
  3. Hi @nisarg_shah114, Could you please send a quote of the Vivado error or a screenshot of it? Without seeing the error I would guess that you need an equivalent library statement to make the library that your custom package resides in visible. If that is the case when you get back to me, I will give you the details on how to create your own library using the Vivado tools. Looking forward to hearing back from you, AndrewHolzer
  4. Hello @nisarg_shah114, The Nexys 4 has an onboard USB host connector with a microcontroller that sits between it and the FPGA. The microcontroller will handle the USB HID protocol and emultates PS/2 bus signals. There will be no need for an external PS/2 to USB converter at all. This section of the Nexys 4 reference manual has details regarding the keyboard connection. The section before it gives details to the HID controller. I hope this information helps you. Do not hesitate to ask any questions you may have, and I will do what I can to help. AndrewHolzer
  5. Hi @dand400, Glad to hear that you've fixed your issue and reported it here! Best regards, AndrewHolzer
  6. Hi @Tech_Enthusiast_007, All you really need is the Zynq Processing System IP core and you'll be on your way. Add the IP core to your design and hit Run Block Automation. This will initialize the block and setup the Ethernet and UART peripherals for you to use. Once that step is completed, you can route the output from FLCK_CLK0 to M_AXI_GP0_ACLK and then hit Validate Design. The tools should tell you that everything is good to go. Create the wrapper, generate bitstream, then export the design to SDK. Once you're in SDK, you can create your project, but base it off the Hello World template to test the UART. You can then start coding your project from there. The Zynq block is just a block representation of the processing half of the Zynq chip, and is required for you to export the hardware description to SDK. I hope that this has proven to be helpful to you! Let me know if you have any further questions and I will be happy to assist you, AndrewHolzer
  7. @Cynthia, I am glad to hear that you were able to find what was giving you troubles and want to thank you for posting your solution. Good luck with the rest of your project! Regards, AndrewHolzer
  8. @Cynthia, I've run through the guide that you linked with the standalone OS. I was able to get everything working with the interrupts from the custom IP core being triggered. Some of the code has depricated, like the Xuint32 data types, but if you follow the warnings that SDK gives you you'll figure it out. You can run the code and see output indicating how many times the interrupt routine has executed. I found that main won't complete execution and never reaches the "Waiting for Interrupts...\n\r" bit. I was able to comment out the xil_printf method in handler() and main was able to complete. Both of these examples demonstrate that the interrupt from the custom IP core is being captured. Let me know if you have any issues trying this out, AndrewHolzer
  9. @Cynthia, Once again I want to thank you for your patience. I want to update here so you aren't left wondering what I've been up to. I have been able to replicate your exact issue where the code executes twice and the interrupt for the timer does not trigger. I've been able to get the peripheral test to succeed on the timer interrupt and exit main, but this was done with a bsp that was made using the standalone OS type. This was done with no changes made to the peripheral test code underneath either the standalone or xilkernal OS type. This leads me to believe that this is an issue with the xilkernal itself. I haven't quite tracked down the issue yet but I am digging further. I believe I am on the right track here though, and will be reading up on the xilkernal to see if I can find out what the issue is. If the application you have in mind doesn't require the xilkernal OS type, I suggest that you try the standalone OS type and see if that suits your needs. Since you are specifically generating the bsp with the xilkernal type, however, I assume it is necessary in someway. I'll keep up my work here and update when I've found something. In the meantime take care, AndrewHolzer
  10. Hi @Cynthia, I want to thank you for your patience. I've been trying to recreate the results you are seeing but have been unable to do so. Can you send me an image of the block diagram of your design? How are you programming the Nexys Video FPGA? What version of Vivado and Vivado SDK are you using? One solution that was recommended to me was to go into your project directory and either delete the *.sdk directory or rename it to something else. Once you have done that, go back into Vivado and export design once more and then launch sdk. Go through the process of creating the Peripheral Test application in SDK and launch it. You want to do this because there can be issues when you update the FPGA design in Vivado and then go back to SDK with those revisions. That could be the reason as to why you are seeing this new issue. Let me know how that goes, and the information I've asked for if this still does not work. Best of luck, AndrewHolzer
  11. @Cynthia, I've noticed that you haven't included a MIG in your block design. I suggest that you follow the Getting Started with Microblaze guide for the Nexys Video for help in setting up a base design. I don't have a Nexys Video on hand myself, but I did run through the same process using my Arty. In my first design iteration, I didn't include a MIG and my design failed as yours did. In my next pass through on the design, I dropped in a MIG and regenerated my BSP sources. I ran the test once more and the interrupt test for the timer passed. There will be a pause of a few seconds when testing the axi_timer, so some patience is required. Let me know if this fixes your issue, and if not I will work with you to find a solution, AndrewHolzer
  12. @artvvb and @jasonbla20, I was also thinking it may be that the IP core is configured with the new UART pin connection, whereas the PmodCLS follows the old convention. I don't see how the IP core would be pushed to release if that wasn't accounted for and have been working on verifying that the IP core accounts for that discrepancy. If you can verify yourself, then go right ahead. It probably isn't the case, but is something that should be kept in mind when troubleshooting this case. AndrewHolzer
  13. Hi @Solomon Kalbore, I answered a similar question here. In short, the center-to-center distance between two PMOD headers is 0.9", so the center-to-center from pin1 on one header to the next should be the same as well. The comment includes a link to the PMOD standard, which has other bits of info should you need it. Regards, AndrewHolzer
  14. Hi @jem2k, I was able to locate the project buried within our server archives. I've included the project zip here for you and anybody else who may be interested in this project in the future. I've also found another project that targets the Nexys2 that does edge detection. I'm going to include it as well as an extra goodie. Good luck with your project! AndrewHolzer 23 Image Capture Watermark - Ceapa.zip 14_Image_Processing_with_Edge_Detection_-_Gidro.zip
  15. Hi @jem2k, I've tried to do some digging to find alternative sources for the project you are asking about. I haven't found anything, so instead I have asked if it possible that the project still exists somewhere on our site. I will return to you when I have an answer. Thank you for your patience, AndrewHolzer