malexander

Technical Forum Moderator
  • Content Count

    101
  • Joined

  • Last visited

  • Days Won

    3

malexander last won the day on May 23

malexander had the most liked content!

About malexander

  • Rank
    Prolific Poster

Profile Information

  • Gender
    Female

Recent Profile Visitors

2167 profile views
  1. @anshumantech I looked at the datasheet for the XC3S400 and it says that the JTAG pins are powered by VCCAUX. It also states that VCCAUX can be 2.5V or 3.3V. Further, it specifies an absolute maximum voltage of 4.6V for all dedicated pins. The VREF pin of the HS1 powers the high speed buffers that drive the TMS, TDI, and TCK signals from the module. If you power the VREF pin at 5V then those buffers have drive strength of up to +32/-32mA and will output approximately 5V on the line for a logic '1', which will violate the absolute maximum input voltage specified for the XC3S400 JTAG pins. Over driving the pins may be what's causing the erratic behavior that you are seeing with the HS1, as opposed with a parallel programmer, which may use different buffers. If at all possible I'd try disconnecting +5V from pin 1 of your JTAG header and replacing it with the onboard 3.3V supply or whichever supply you use to power VCCAUX. Thanks, Michael
  2. @anshumantech Are the XC3S400 and XCF02S actually powered at 5V or are their JTAG signals referenced to 3.3V or some other voltage? Are there any buffers/level translators omitted from this diagram? I believe that you said you were able to successfully configure the XC3S400 with the HS1. If that's true, did you try configuring it with XCF02S in the scan chain or was it omitted from the scan chain by shorting pins 1 and 2 of J13? If you haven't tried configuring it with the XCF02S in the scan chain then it would be interesting to configure it with that device in the chain. Perhaps configuration would succeed but read back would fail. Thanks, Michael
  3. @anshumantech You're impact results from above strongly suggest a timing or signal integrity issue and just because iMPACT claims to program have programmed the XCS3400 successfully doesn't dismiss the need to further investigate those issues. Can you send me a schematic that shows all of the JTAG scan chain and tell me the reference designator of the header that you are plugging the HS1 into? Thanks, Michael
  4. @varunnagpaal I took a brief glance at the Snickerdoodle schematics. There appears to be an arm processor (STM32F078VBH6) attached to the JTAG pins of the Zynq through RN9, which is drawn as 10 ohm series resistors. If the STM32 is driving the JTAG lines then the JTAG-HS3, or any other external programmer, will not be able to communicate with the Zynq due to a drive conflict. I didn't take the time to investigate this any further but if I were you my next step would be determining what the purpose of the onboard STM32 is and figuring out if it's supposed to somehow be used to communicate with the Zynq over JTAG. I suspect removing RN9 would solve the problem and allow you to communicate with the Zynq through the JTAG-HS3 but I think you should contact krtkl about JTAG functionality over header J2 prior to modifying your board. Thanks, Michael
  5. The data length should be 0 when transmitting the enumeration message. I don't see a baud rate setting in your screen shot. Please make sure you have it set to 1 Mbaud. Thanks," Michael
  6. @anshumantech It's interesting that the ID code changes based on the chosen TCK frequency. This suggests that there may be some signal integrity issues. How are you attaching the HS1 to the board that contains the device that you are trying to program? Is it plugged directly into a header on the board? Does the board contain additional resistors in line with the JTAG signals? What voltage is the JTAG scan chain operating at, and is the VREF pin of the JTAG header, and more importantly JTAG HS1, being powered at the correct voltage? Thanks, Michael
  7. @wfpga The USB shield is AC coupled to ground through a 1nF capacitor with a 1M ohm bleed off resistor, which is the same way we’ve connected USB shield on 95% of our boards. I just reviewed the datasheet for the LTC3589 regulator and I don’t see any issue with the existing power supply design. Sure the diode adds an additional voltage drop (approximately 350mV at 500mA) that would result in VU being below 4.5V when VBUS as seen by the device is 4.5V, but its still over 4V, which is well above the undervoltage lockout threshold (2.5V) and well above the area where the output would be unregulated because the LTC3589 is capable of 100% duty cycle and at 4.15V the duty cycle is ~80%. If the input voltage were to drop low enough that 100% duty cycle were required to output 3.3V then the minimum voltage for VU would be (0.265*0.6)+(0.170*0.6)+3.3 = 3.561V so I don’t see this being an issue. Using an external power supply may give you a better ground reference then the one provided by the USB cable and provide better noise immunity, especially in the case of a poorly constructed USB cable.
  8. malexander

    DMC60c CAN Bus

    @opethmc I think reducing the baud rate should be fairly simple but this will result in an image that's not compatible with First Robotics Competition and it wouldn't be compatible with our configuration utility, which runs on a RoboRio in the FRC environment. Assuming that I can find time to make such an image what baud rate did you have in mind and how many devices were you planning on having on the bus? Thanks, Michael
  9. One thing I forgot: if you install ISE 14.7 and have it install the cable drivers then there shouldn't be any need to manually install the Digilent plugin.
  10. @anshumantech The Adept GUI application was developed to provide a lightweight application for programming the FPGA and flash memories on Digilent system boards. It was not meant to be a general purpose programmer for all CPLD/FPGA/Flash combinations, and as a result we only tested the device combinations that were on Digilent system boards. We recommend using iMPACT 14.x with out plug-in for general purpose programming of older CPLD and Flash devices. For newer devices we recommending using Vivado. I don't think Vivado supports the XCF02S but I know it's supported in iMPACT. Have you tried using the HS1 and iMPACT with the Digilent Plugin to program the XCF02S on your board? You don't need a license to use iMPACT (part of ISE) for programming and you can download 14.7 here: https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools.html https://store.digilentinc.com/digilent-plugin-for-xilinx-tools-download-only/ Thanks, Michael
  11. @adambro What value are you passing for the fOverlap parameter of DspiPut? Are you running the same Linux distribution on both Linux PC's and is the architecture the same? What is the architecture: x86, x64, or arm? Thanks, Michael
  12. @DJOConnor XC3S400 is an old device and my guess is that we most likely designed one or more part from the same family onto a Digilent board, tested it, and assumed it would work for all parts in the family and didn't explicitly test programming an XC3S400. We never really intended for djtgcfg to be used as a general purpose FPGA configuration tool... we only intended for it to be used to configure the devices that were on Digilent System boards. Now that ISE and Vivado both include integrated support for our programmers there is no need to add support for new devices, nor is there any motivation to go back and test any of the legacy devices that aren't utilized on active Digilent system boards. If we do another release of djtgcfg then we will likely remove all legacy devices from jtscdvclist.txt so that those devices end up being unrecognized by djtgcfg and then have jtsc spit out a message that says to use iMPACT or Vivado. In the end the solution is to use iMPACT or Vivado, both of which have the programming algorithms built in and tested by Xilinx. Thanks, Michael
  13. If you want to probe the OEx signals as they appear coming out of the USB controller then R25, R24, and R5 are the easiest locations to access. If you want to probe the GPIO signals as they appear coming out of the chip then R29, R28, and R34 are the easiest locations. Those are in order of 0, 1, 2. Just to confirm, you are asking about the the JTAG-SMT2 or JTAG-SMT2-NC and are trying to use the GPIO's in OpenOCD?
  14. There are directional buffers between the FT232 and the actual GPIO pads on the module. The direction of these buffers is controlled by the logic level that's applied on the OE0, OE1, and OE2 nets. Placing a '0' on the OEn net will configure the applicable buffer as an output and allow the signal to be driven out of the applicable GPIO pad. Placing a '1' on the OEn net will configure the associated buffer as an input and allow the FT232H to read the state of the applicable GPIO pad.
  15. malexander

    DDR3 input clock source

    There is only a single 100MHz oscillator that's loaded (IC3). The other one (IC2) is not loaded. In order to meet timing the DDR reference clock and DDR system clock have to be in the same column as the bank that contains the DDR3 interface. I don't recall what the thinking was when we included the 12 MHZ USB clock (UCLK) that goes into Bank 15, but you should be able to clock the entire device from pin R2.