PaulW

Members
  • Content Count

    18
  • Joined

  • Last visited

Everything posted by PaulW

  1. Yeah, fixing the VHDL in the wrapper did the trick for me, I am getting SCL clocking now. Thanks again for the help.
  2. This has helped my problem: https://forums.xilinx.com/t5/UltraScale-Architecture/I2C-through-EMIO/td-p/984165 particularly: " As would be expected this turned out to be something very simple. For I2C not only is the SDA bi-directional but SCL is also, but I had not set up the return path for SCL. So the controller was always waiting to see the SCL line high before starting anything and that's why both SDA and SCL showed no activity even on the ILA. In the vhdl wrapper for the block design just the second line below was the fix: <SCL I/O pin name> <= I2C1_scl_out when (I2C1_scl_tristate = '0') else 'Z'; I2C1_scl_in <= <SCL I/O pin name>; -- <- This was the missing vhdl line that I needed to add in the wrapper vhdl file <SDA I/O pin name> <= I2C1_sda_out when (I2C1_sda_tristate = '0') else 'Z'; I2C1_sda_in <= <SDA I/O pin name>; Thanks for the help on this.
  3. Thanks for your feed back D@n, I will explore these.
  4. D@n, I am also working on this problem. Thanks for your input. I instantiated an ILA in the FPGA fabric and looked at the signals coming out of the Zynq-Arm core, see the picture included. When we try to access the Ps7-I2C peripheral, I see toggling on the I2C0_SCL_T signal. Interesting that it does not stay low, it goes back active high, implying to me that the SCL line is to be tri-stated, as if the Zynq-Arm was expecting to be a slave I2C device. I see no toggling on the SCL line, even when trigger only on it (in the FPGA fabric) after multiple accesses to the ps7-I2C peripheral. I checked through the XDC file and the pinout for the Zynq on the Cora board seems correct. I route the signals coming out of the Zynq-Arm to the block design wrapper (VHDL). I then just drive the SCL straight out of the Zynq, without any tri-state buffer, but I do tri-state the SDA line as required. Any more thoughts? Thanks again. --Tri state buffer for I2C interface I2C0_SCL <= I2C0_SCL_O; I2C0_SDA <= I2C0_SDA_O when (I2C0_SDA_T = '0') else 'Z'; I2C0_SDA_I <= I2C0_SDA;
  5. I will update this thread as I find any other software issues when using the Analog Discovery2 with the Cora board. I expect that I will continue to have Cora programming issues and if I find any resolution, I'll post.
  6. Well, I'm back up and running. For what its worth, this is what I did: 1. Uninstall Waveforms, then reboot PC 2. Re-install Waveforms 64bit, then reboot PC 3. Start Waveforms in safe mode - it worked. Then started Waveforms in normal mode - it still worked. Not sure what the problem was but I'm back up and running.
  7. I have been using Analog Discovery2 and Digital Discovery for over a year now with Waveforms and it has always worked as expected. Recently we started an embedded project using one of the Cora boards. I have noticed sporadic problems with Waveforms when I have both the Analog Discovery2 plugged in and the Cora board plugged in (to USB.) Problems such as the Xilinx SDK not being able to program the Cora board and Waveforms not being able to see the Analog Discovery2 module. Now, I have gotten to the point where I cannot even launch Waveforms at all. It just hangs, I don't even get to the demo mode screen. I have tried uninstalling and then re-installing both the 32-bit Windows version and the 64-bit Windows versions of Waveforms and neither works - they both hang, not allowing me to even see the demo screen. I don't even have any hardware (Cora or Analog Discovery2) plugged into the computer. It seems that perhaps my registry has been messed up. Do you have any app notes or suggestions on what I can do at this point? I sure would like to use Waveforms My system specs: Intel i7-7700HQ CPU at 2.8GHz, 16GB RAM, 64-bit operating system, x64 based processor Windows 10 Pro, version 1709, OS Build 16299.1087 Any help is much appreciated. Been searching the forums for similar topic and have not found any yet.
  8. Shifting the 32-bit value right by 1 bit works for every pattern that I am trying. Well at least I can now use this to do my troubleshooting, I sure would like to know why I have to shift my desired trigger value by one bit. Thanks for the help.
  9. I downloaded the latest Waveforms, Version 3.9.1 64-bit Qt5.6.3 Windows 10 and the behavior got better. I can now reliably trigger on hFFFFFFFF (see picture), but still cannot trigger on other patterns like h18A218A2 which I know is in the data - because I capture random data by triggering on a START condition and the pattern h18A218A2 is almost always appears. Using Waveforms (NO LIMITS) and using the Advanced triggering seems to do no good. Could the digital trigger logic be getting confused because I do not terminate each SPI transfer with a rising edge on Select? I found the problem - I can now trigger on my desired pattern of h18A218A2 but I have to enter in that digital pattern right-shifted by 1 bit ==> h0C510C51. When I enter this value into the SPI protocol trigger - I am triggering as I desire - I see the pattern of h18A218A2 in my waveforms (despite that I am triggering on h0C510C51.) Any ideas as to why this is? Why is the trigger pattern requiring a shift by 1 bit?
  10. I tried using Waveforms on a Windows7 machine and got the same behavior.
  11. It is also unexplained why entering a SPI value = h00000000 causes the trigger to occur mutliple times, but it is not triggering on h00000000, it is triggering on any random pattern, usually the first full 32-bit pattern that comes available. I have also tried using the advanced GUI but it does not seem to help. It works for triggering on START and STOP conditions, but has the same behavior when trying to trigger on a VALUE.
  12. I also notice that when I try to enter a Value in the SPI Trigger menu, there are several selections to choose from - or I can type in my own value. I do not recognize the patterns that are available to choose from, where do these come from? I did not enter these specific values. Is this a clue to the problem? See picture included.
  13. I still can't trigger on a specific value when using the DD at 800MHz. I have 3 Ground connections between the DD and the prototype board I am working with.
  14. Attila, I am capturing the data just fine when using a SPI protocol trigger = START or STOP event. So the ability to capture the data patterns is working. The device does not seem to trigger on a specific 32-bit value after deserialization. Any other ideas or things to try?
  15. Hello, I am having difficulty using the SPI Trigger Value feature. I have one SPI interface running at 8MHz. I am using a Digital Discovery (but also have an Analog Discovery 2 that behaves the same way.) I have connected my SPI channel to the Digital Discovery and then use a Normal Trigger, SPI Protocol, START condition, which works fine. I can also trigger on the STOP condition and it works fine. But when I choose Value and select the value I want, the device does not trigger. I know that the value is in the SPI data stream because when I trigger on START, STOP or just simple clock triggers, I always see the 32-bit value I am trying to trigger on. It seems that my SPI protocol trigger Value feature is not working. I have tried using Waveforms in both modes (normal and NO LIMITS) and cannot get it to work. I have included snapshots of my Waveforms GUI with some more explanation of the problem. Appreciate any help you can give me.