• Content Count

  • Joined

  • Last visited

  • Days Won


juergenR last won the day on September 1 2018

juergenR had the most liked content!

About juergenR

  • Rank

Recent Profile Visitors

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

  1. 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 a full PS reset and the programming of the PL, but I did not test this. BR, Jürgen
  2. 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.
  3. 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 the Zynq block seems to be OK and checking the Xilinx forums also did not reveal anything useful. Of course without clock, no data will arrive at the display. Does anybody know why this can happen? How to ensure that PS is initialized correctly? Does the program code from SDK ensure this in all cases? I guess I am missing a slight detail... Thanks for your help, Jürgen
  4. 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 and push buttons axi_gpio1 --> 0x41210000, 16 out, 4 in on chipKit shield pins 3. Create Linux system Strightforward: import hardware into project, build and package. Don't forget to clean your project when you copied it from an existing one. Modified system-user.dtsi: /include/ "system-conf.dtsi" #include <dt-bindings/gpio/gpio.h> / { model = "Zynq Arty Z7 Development Board"; compatible = "digilent,zynq-artyz7", "xlnx,zynq-7000"; chosen { bootargs = "console=ttyPS0,115200 earlyprintk uio_pdrv_genirq.of_id=generic-uio"; }; ... }; &axi_gpio_0 { compatible = "generic-uio"; }; &axi_gpio_1 { compatible = "generic-uio"; }; ... Running system then exposes uio0 and uio1 devices. So far the project wasn't difficult, problems arised when I went over to programming... Please note, that for that SDK can find the generated libraries and include files, you have to copy the folder "<plnx-project>/build/tmp/sysroots/plnx_arm" into a Windows folder; the copy need to resolve all symbolic links (cp -R -L)! 4. Create Linux application Within Xilinx Wiki and in this Forum there are quite a bunch of useful posts; however, most of them just explain the principal way and neglect some details. Unfortunately, this turned down to that the program might work just once after reboot or events are not triggered even they occur or the supporting libs use other ways to access the data... Here's what I finally did: Create linux project and connect to the copied libaries: Modify Linux gcc libraries and Miscellaneous settings (right click on project, then choose C/C++-Build Settings). Within "Miscellaneous" you have to set --sysroot="C:\VBox\Exchange\pl_libs\plnx_arm" Please note, that the library name is "uio" but the file name is "libuio.so". The latter will not be recognized. it turned out, that libgpio isn't helpful when using interrupts due to hiding the file handle and only exposing the memory pointer. However, the libuio works well within this context. Set up of the UIO should be like this: // map to ports UIO *uio_h = UIO_MAP(uiod[0].uio_nb, uiod[0].map_nb); void *uio_m = uio_h->mapPtr; int uio_fd = uio_h->uio_fd; //file handle for blocking read from uio // init ports writeGPIOPort(uio_m, GPIO_TRI, 0); // all outputs channel 1; writeGPIOPort(uio_m, GPIO2_TRI, 0xFFFFFFFF); // all inputs channel 2; writeGPIOPort(uio_m, GPIO_DATA, 0); // all outputs set 0 writeGPIOPort(uio_m, GIER, GIEn); // global interrupt enable writeGPIOPort(uio_m, IER, 0x02); // enable interrupts only on port 2 (inputs) uint32_t actIStat = readGPIOPort(uio_m, ISR); // toggle ISR bits to '0' writeGPIOPort(uio_m, ISR, actIStat); write(uio_fd, &reenable_int, sizeof(int)); // enable catching interrupts within driver catching interrupts within the program writeGPIOPort(uio_m, GPIO_DATA, 1); // set some output ires = pread(uio_fd, &evt_count, 0x04, 0); // wait for int (blocking read) call some_action(); actIStat = readGPIOPort(uio_m, ISR); // toggle ISR bits to '0' writeGPIOPort(uio_m, ISR, actIStat); write(uio_fd, &reenable_int, sizeof(int)); shutting down at the end: ires = UIO_UNMAP(uio_h); 5. Explanations we have to write the value "1" to the file descriptor to reenable interrupt handling within the linux driver (thanks to Yohboy for pointing me to this) - otherwise only one interrupt will be cought. prior to writing to the file descriptor, the ISR must be reset. Otherwise the previous interrupt will be reexecuted. pread will not forward the file pointer (I don't know if this is of relevance, I didn't test it again with read()) pread will block till a new interrupt arrives. This is usually a good way when executing the code within a separate thread. For non-blocking behaviour, you will need to use poll (as suggested by Yohboy) or the newer epoll functions. I tested both blocking and non-blocking behaviour and both worked well. 6. Performance Of course Petalinux is no real-time OS, so we cannot expect too much especially from the interrupt behaviour. But I was interested in some figures to know the limits. Toogle output bit as fast as possible: I have been measuring a cycle time of 525ns - this is really fast! However, I did not try to measure any jitter on this. Interrupt delay: here much higher delays come into play as well as a strong jitter. The minimum delay was about 12us but could go up till 80us. This is still very fast and might catch every bounce on a push button, so for many processes interrupt handling might be useful instead of polling the inputs. 7. Closing Remarks As written at the beginning, I want to summarize things and provide a solution (hopefully) ready to be run, especially for using interrupts on GPIO. The explained solution is based on proposals provided by several people around in the forums, at Digilent and at Xilinx, so thanks to all of them which gave me hints to proceed. My solution will not be perfect, so any improvements ar welcome. Cheers, Jürgen gpio_test.c
  5. 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. The config then looks like inside the screenshot. Hope this will help for anyone developping Linux apps. Cheers, Jürgen
  6. 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.
  7. @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?
  8. 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
  9. 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 (petalinux-config -c kernel) 5. After that, building the project succeeds and booting the whole thing from a SD card works fine. No time-out errors and adding the kernel module and starting the app works fine too. But when building the same project with I2C ports enabled (hardware and kernel), but packing/starting it with the hardware without I2C will give no time-outs, too. Thats something strange, isn't it? At least I learned now that I can use Petalinux projects from scratch with the Arty-Z7 board and I am not forced to derive from the Digilent template - thats already quite good! Now next step will be to have the app and the module integrated within the linux from build time on...
  10. 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
  11. I recently ported two tutorials for Vivado 2017.4 - the actual Arty-Z7 examples are not fully ported to that version. They are available on github: https://github.com/juergenRe/Arty-Z7-XADC-VHDL https://github.com/juergenRe/ArtyZ7-20-CDMATutorial The XADC demo is originally written in Verilog - because I am usually using VHDL I took this as an occasion to dig deeper into that example. Also, I added a simulation bench (which normally is the first step when creating custom logic) The second project is a port from Xilinx UG1165 tutorial using the centralized DMA IP. This was a bit tricky due to differnt RAM size and a strange error in Vivados connection automation (see that post: Wrong connection on AXI, evtl. somebody might provide ans answer?). I recommend working through UG1165, you'll learn a lot about how to use the SDK even sometimes you'll need to guess how to adapt to the Arty. There are also covered a lot of things concerning IPs and IP Integrator, so I feel, the additional time spent there is worthwhile. Please note that repositories might contain issues, I did not test to the full extend. If theres someting missing, please feel free to add or correct or leave me a message.
  12. Deleting the existing Zynq block and adding a new one will give you the possibility to apply the presets. However, any configuration change you did before (e.g. adding gpio, ddr ports etc.) will be lost. Even if there are connections created between blocks - these will be deleted then. Actually I stored a preset from a design which is a bit more complex and use this for other designs. Not used things can be switched off later. As long as my understanding of the Zynq block isn't that good, I prefer starting with something validated instead of searching to much in the settings.
  13. After some restarts of the VM that behaviour disappeared - now rebuilding the image after a config change (adding one more Digilent app) works fine. Don't know why but so far I am happy now. Juergen
  14. Hi everybody, my name is Jürgen and besides my work as research engineer I am doing some fun work with FPGA and analog electronics/signal processing. Some time back I started with a LX9 Microboard and recently bought an Arty Z7-20.