PaulW

Members
  • Content Count

    18
  • Joined

  • Last visited

Posts posted by PaulW


  1. 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.


  2. [email protected], 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;
        

    I2C problem on Cora1.png


  3. 1 hour ago, attila said:

    Hi @PaulW

    Good to hear it is working and thank you for posting the solution.

    The problem could have been with the Adept Runtime version. The Xilinx SDK installing/downgrading to an older version of this.
    The WaveForms also installs/uses this Runtime and due to frequent releases contains the latest version.

    The Xilinx processes may remain in background, blocking access to devices.
    In this case you could kill the hanging process from TaskManager or reboot.

    OK, thanks for that info, I'll give that a try.


  4. 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.


  5. 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?

    Digital Discovery SPI protocol trigger issue2.png

    Digital Discovery SPI protocol trigger issue3.png


  6. 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.


  7. 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.

    Digital Discovery SPI Protocol Triggering Issue1.png