JColvin

Administrators
  • Content Count

    4305
  • Joined

  • Last visited

Posts posted by JColvin

  1. Hi @Thomas4086,

    I'm not certain why Adept would not be able to find the dpcomm.dll. As a first step, I would probably try uninstalling and then re-installing the Adept software.

    As an additional question, do you happen to have the Digilent Agent running on your computer; I have seen it using the dpcomm.dll which can cause update issues.

    Thanks,
    JColvin

  2. Hi @pcdeni,

    The NetFPGA group has created all of the materials and provides support for those materials for the NetFPGA SUME. Digilent does not have any reference designs or support for the SUME board. The mailing list for the NetFPGA SUME, which you should have access to if you signed up for access to the official repository, would be able to provide additional help regarding this.

    Thank you,
    JColvin

  3. Hi @chrisD,

    This is not possible to do with the OpenScope MZ, though simultaneous logging and viewing of the data on the OpenLogger is possible.

    My understanding is that the OpenLogger does simultaneously log chunks of data to the SD card while viewing the data in WaveFormsLive. However, I do not think you can configure the size of these chunks or when the OpenLogger logs  Each chunk of data that is logged during that time will be labeled with the first sample number associated with that chunk (and each entry will show the time stamp in relation to the very first sample at the start of the logging session).

    Let me know if you have any questions about this.

    Thanks,
    JColvin

  4. Hi @Leo_W,

    I asked another engineer much more familiar with Adept and the JTAG modules about this (they created and developed both), but they did not have any further suggestions or know what the problem might be. The only thing that they noted was the diodes on the JTAG lines which increases capacitance and could cause signal integrity issues, but it's unlikely this is the problem since you are able to consistently access and program the board through Adept through the SMT2-NC.

    From what I understand, Adept doesn't do anything different than Vivado in terms of detecting a downstream FPGA board (though it is more limited as to what types of boards that it supports). If I'm not mistaken, the Digilent cable drivers that are part of the Vivado installation come from Adept in the first place.

    I wish I could offer some useful advice that isn't reinstall/use a different version of Vivado (I imagine you've tried it by this point), but I don't have any other debugging techniques that you could try.

    Thank you,
    JColvin

     

  5. Hi @Wayne Contello,

    I don't know the implementation within WaveForms itself, but I suspect your conclusion of the trigger only using a 7-bit address is correct as true 8-bit addresses (as far as I understand it) don't formally exist within the I2C specification. I think @attila is out of the office right now, but they will be able to see your feedback and clarify the implementation.

    Thanks,
    JColvin

  6. Hi @Soufyane,

    You can rename any IP in a block design. Just click on the IP so the whole block turns orange, then go to the General tab in Block Properties (you can also press CTRL+E or right click on the IP block to get to the Block Properties). There will be Name field in the General tab where you can type any name you want, which can be helpful for when you have multiple of the same IP block, such as AXI_GPIO, that you want to more readily identify.

    What do you mean by it crashes in addPin? Vivado crashes? Where are you seeing the addPin function?

    Thanks,
    JColvin

  7. Hi @RONVROD,

    I apologize for the delay.

    I want to make sure I understand your setup and what you are experiencing correctly; if you only intermittently provide power to the VRM by turning on your switch (in your example, the car horn), which correspondingly provides power to the garage door opener, no signal is transmitted? I have attached a generic sketch of how I am imagining this setup to look.

    Presuming the above is the case there are a couple of things that can think of that might be contributing to the problem (and other things)

    - The garage door opener needs more time to "power up" before it can send a signal. This would explain why leaving power attached and then enabling the regulator (disable the regulator by pulling the Enable pin to ground and unattach it/leave it floating to enable the regulator) does successfully cause the remote to work.
    - The garage door opener expects a slightly different voltage. I'm guessing that the remote uses two AA batteries which usually works out to around 3V. Providing 3.3V might work, though depending on the internal circuitry of the garage door opener it might have it's electronics wear out sooner than you expect.

    Thanks,
    JColvin

    garageOpener.png

  8. Hi @MarkSe,

    Looks like I forgot to add that it; it should be SPI Mode 3, where the leading (and falling) edge indicates to the part to "load" the data and the trailing (and rising edge) clock edge is when that data is valid and should be read. I remember there being a point of confusion on where the extra bit is since the ADC datasheet says that 16 clock cycles are needed to complete a reading, but only 15 bits are described (3 leading zeros, 8 bits of resolution, 4 trailing zeros); I don't recall where the the final (presumably extraneous) bit is located; at the beginning or at the end of the 16 bits.
    Unfortunately, I don't have a Pmod ALS with me to test though the Arduino code makes it look like I decided this extra bit was at the beginning. This seems to be backed up by the line "If CS goes low before the rising edge of SCLK, an additional (fourth) zero bit may be captured by the next falling edge of SCLK" on page 12.

    The waveform itself looks like it's wrong since the clock isn't idling high. Or, I suppose it's possible to still run the code as is with the clock idling low, but you would need to tell the Saleae to not start interpreting data until the second rising edge, as you already concluded. The interpretation that it made based on the rising edges is accurate.

    Let me know if you have any questions about this.

    Thanks,
    JColvin

  9. Hi @MarkSe,

    Your waveform looks a bit off. The embedded TI ADC081S021 (link to datasheet) does not start loading data until the first falling edge of the serial clock after CS has already fallen; that bit is then valid on subsequent rising edge of the serial clock (SPI Mode 3). Additionally there are 3 leading zeros, followed by 8 bits of data, followed again by 4 trailing zeros. It looks like your logic analyzer is sampling on the correct edge (I presume that is what the small dash on the rising edge indicates) but the serial clock doesn't provide it's first falling edge until after it starts sampling.

    The clock rate looks to be around 1.5 MHz which falls in the recommended frequency range for the serial clock.

    To answer your specific questions, I wouldn't expect such a drastic range though there will be some variance thanks to the spectral characteristics of the light sensor itself. We do not have any verilog libraries for the Pmod ALS, though we do have a Pmod ALS IP core for it.

    Let me know if you have any questions.

    Thanks,
    JColvin

  10. Hi @T.O,

    It looks like you're using some clocking features (DCM_CLKGEN) from Spartan-6 devices that no longer work or are unreliable with 7-series devices as per pages 22 and 23 of UG472 from Xilinx. You'll instead want to use a MMCM and/or PLL to create this clock. There are examples of both in the Language Templates within Vivado or you can use the Clocking Wizard IP.

    Let me know if you have any questions.

    Thanks,
    JColvin

  11. Hi @Soufyane,

    You don't have AXI_GPIO_LED in your xparameters.h because you didn't rename the AXI GPIO IP in your block design (as done in the video, Digilent YouTube video link, around the 4:30 minute mark). You can either rename the AXI GPIO block names to AXI_GPIO_LED and AXI_GPIO_SW as mentioned in the video and regenerate the bitstream to get the proper hw_platform/.xsa (depending if you are using SDK or Vitis) or just use the existing name of the IP (I'm presuming this is AXI_GPIO_0 and AXI_GPIO_1 though I can't see them on your block design) in xparameters.h/deWebIOServerSrc.cpp and adjust any changes as appropriate as explained starting around the 8:30 minute mark. You'll still need to make sure the width is adjusted as appropriate.

    Let me know if you have any questions about this.

    Thanks,
    JColvin

  12. Hi @tlandry48,

    What sort of logic are you wanting to do to these inputs? You are likely correct in that you will need two separate boards; a system board and some sort of external add-on that handles the dozen or so inputs that range from 0 to 10V, or at least Digilent does not have an all-in-board that meets this criteria.

    The only board that Digilent has that can handle up to 10V as is would be the Analog Discovery 2, though it only has two oscilloscope channels.

    Thanks,
    JColvin

     

  13. Hi @srce,

    I don't have a Genesys 2 with me at home to readily test this, but what settings do you have JP4 and JP5 set to? A picture of how they configured will work for me. I agree with your assessment that keyboard is continually being reset since that's the scancode it sends out when receiving a 0xFF from the host or upon keyboard power-up. Since that particular demo doesn't send any scancode commands to the downstream device at any point (it only reads them), this would make me think that the keyboard is instead being continually reset.

    Edit: I see your latest post about the other keyboard working aside from some of the arrow keys. I will ask about the firmware used in the PIC24.

    Thanks,
    JColvin