juergenR

Members
  • Content Count

    20
  • Joined

  • Last visited

About juergenR

  • Rank
    Member

Recent Profile Visitors

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

  1. Thanks for your answer and suggestions. I am happy you got my point. For the Arty-Z7 board: actually those pins seem to work still as intended and I will follow your proposals. 🙂 BTW, I still believe that the current flow out of the CLP is unusal high and I am not sure if my CLP has a damage elsewhere. Maybe it is worth to check the nominal current flows in and out of the controller - unfortunately I don't have reliable information about them. Best regards, Jürgen
  2. I used an Arty Z7-20 board, using PModA connector. Power supply via USB, nothing else connected. The connection to the PModCLP was like this (Z7-20 --> CLP): Pins 1..4 --> DB4-7, Pins 7..10 --> Control signals. DB0..3 left open. Used a cable I bought also together with the CLP. Hope this helps, Jürgen
  3. Hi, these days I found a PModCLP I purchased some years ago and decided to reimplement the control for it. In particular, I decided to operate the module in a differnt manner: use the 4 bit mode to spare some lines read status bit to know when a command has been finished As a consequence, there is bidirectional data transfer on the data bus including High-Z phases and DB0 to DB3 will be left unconnected on the hardware. When measuring DB7 to see the status, I got quite surprised because I measured up to 4.8V on the data line - far beyond the PMod specs! When looking a
  4. Have a look here, too: https://forum.digilentinc.com/topic/16550-uio-access-including-interrupts-when-using-petalinux/ BTW, you are not locked to use the older tool chain; I am actually using 2019.1
  5. Hi, Jon, thanks for your reply. Finally I figured out what my mistake was. The board boots a Linux project and on other experiments I never encountered problems just starting the SDK generated program. For this case I also assumed that ps7_init will put everything right, but which apparently is not true. The whole demo works fine, as soon as I stop booting within U-Boot. This allows me on one hand to program the device using the Vivado hardware manager as well as starting the test program from the SDK. Another possibility would be to change the run configuration to include
  6. Yes, I can confirm that I am using the 2018.2 release of the example together with Vivado 2018.2 and the board files installed. Bitstream generation works fine, PL gets programmed. I have no doubt that your example is correct and will work. Actually I assume the problem is linked to some sort of "misconfiguration" of the PS I am not aware of - but I have no real clue where to look at.
  7. Hi, since Digilent posted a new version of the HDMI out demo using Vivado 2018.2, I gave this project a try again. Using the ReadMe I got quickly to a running program in the SDK, everything seemed to run as expected - however, no picture. So I tried to debug the BD - which is a nice excercise in its own. First I checked the locked status of the AXI4Stream-to-video-out block: Locked is reset, but underflow is set. It seems, that there is no data transferred. When debugging the signals from the vdma, I realized after several tries, that PL clock FCLK1 is not enabled. Configuration of t
  8. Past two weeks I fighted to get a simple linux app running being able to read/write to an AXI GPIO IP using interrupts for the inputs. There a quite a bunch of links out there, each describing a part of the problem. But glueing all together into one system wasn't that easy as expected. Goal of that post is to summarize the things and open a discussion. 1. Systems used - Vivado 2017.4, SDK 2017.4 (Windows), Petalinux Tools 2017.4 on Ubuntu 16.04LTS running as VM - Arty Z20 as hardware platform 2. Block diagram axi_gpio0 --> 0x41200000, 4 out, 4 in connected to LEDs a
  9. I stumbled over the same issue. The solution mentioned here: https://forums.xilinx.com/t5/Embedded-Development-Tools/Trouble-creating-Linux-Application-in-SDK-2016-2-or-2016-4/td-p/752561/highlight/false/page/2 did not work properly, because the copy from Linux world to Windows world will cut the symbolic links and thus linking will fail. To solve this, use "-L" option within the copy command. Otherwise the solution is OK. However, this will solve the include issue, but when it comes to linking the modules it again fails. Here you have to add the modules with "-l" option inside the SDK. T
  10. Thanks again for your help. One of the missing links was that I never saw the system.dts file; now I know how to generate them. Now I have some starting points, thats very good.
  11. @sbobrowicz, Thanks for your help. Unfortunately, your link doesn't work; do you instead mean https://github.com/Digilent/Arty-Z7-20-base-linux? When I initially posted, I didn't follow mentioned points 3 and 4 (and 5, but thats seem to be optional) . After searching a bit through other posts, changing device tree file remains somehow "black magic". So I didn't touch it for the moment. Is there addional information somewhere on the meaning of these entries?
  12. Most examples for Arty Z7 are based on Vivado 2016.4, some of them have been ported to Vivado 2017.4, none of them I have seen yet with a 2018 version. You might consider opening, upgrading and rebuilding the block diagram prior to compiling the software within SDK. I managed to do so for Vivado 2017.4 and the whole project compiles and starts. But it crashes somewhere when accessing the HDMI settings... So it is likely that such an upgrade needs a bit more insight in the whole stuff 😉 Jürgen
  13. Thanks for your support - I'll wait for what you will find out. In the meantime I checked also a few questions here in the forum and did some tests, because I came to the conclusion that my modification probably gives inconsistency between project and hardware. 1. Modified the Zync config, so that no I2C ports are used. 2. Created a new petalinux project from scratch, reading in the hdf file as mentioned in the docs 3. Then adding the new kernel module as describeb in UG 1165 4. Building the project gives an error; this can be resolved by disabling I2C within the kernel drives
  14. When experimenting with custum IP and device drivers (following UG1165), I disabled both I2C ports on the Zynq within the BD. When bundling the compiled bitstream with a modified Petalinux for the Arty-Z7, this gives continous errors in the terminal (cdns-i2c e0004000.i2c: timeout waiting on completion) after starting the image. These errors disapperaed after enabling I2C in the BD and recreating the image. Is there a possibility to deselect I2C drivers within the Petalinux project? Where do I find them? Thx, Jürgen