• 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. 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 at the schematics (RevB), I see this VTerm2.5 stuff which I guess should limit the voltage on the 3.3V inputs. But I don't understand how this can work: as soon as an open DB pin exceeds 2.5V + 0.7V = 3.2V current will flow back to IC1, increasing voltage at that output. The regulator will shut down and the whole VTerm potential will mount, affecting also the other outputs. Actually I measure 4.6 at C1 when grounding DB0 to DB3, a bit more when leaving all DBs open. As I understand it, this circuit will only protect outputs but not inputs. Am I right or do I miss someting? BTW, measuring the current to ground on a DB pin gives me about 2.5mA, and a total of 18mA for all 8 pins. This is too high compared to what the KS0066U datasheet states. Does anybody have other measurements? Thanks for any comments, J├╝rgen
  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 a full PS reset and the programming of the PL, but I did not test this. BR, J├╝rgen
  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 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
  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 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)! EDIT 3.1.2020: The UIO also needs to be configured in the kernel. See here: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842490/Testing+UIO+with+Interrupt+on+Zynq+Ultrascale. This procedure also runs with later version of Vivado, SDK and PetaLinux Toos. 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. EDIT 14.3.2020: "libuio" and "libgpio" are libraries provided by Digilent in their PetaLinux distribution. When creating a PetaLinux from template as described above, these libraries are not included and changing sysroot will not work: those files are not included in the created sysroot. However, this is not a problem: you just need to include those libraries directly into your application project. These libraries can be found here: https://github.com/mitchellorsucci/libgpio. 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
  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. The config then looks like inside the screenshot. Hope this will help for anyone developping Linux apps. Cheers, J├╝rgen
  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 (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...
  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