Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


malexander last won the day on January 22

malexander had the most liked content!

About malexander

  • Rank
    Prolific Poster

Profile Information

  • Gender

Recent Profile Visitors

2345 profile views
  1. @Don Koch Excessive heat suggests that there may be a damaged component on the board. The reset line is active low and is driven by an open drain buffer that has a 100 ohm series resistor between it and pin 14 of the JTAG connector. There is no onboard pull-up on the reset line and it is assumed that the host board will pull the line to the inactive state (high). When you say reset is not being asserted, do you mean it's always high or always low? Does your board have any push-pull buffers that drive the reset line? When you say remove power do you mean remove the USB cable or remove VREF from pin 2 of the JTAG header? The onboard buffers will tri-state when they aren't powered. However, the output buffers are powered from the VREF pin of the JTAG header, while the USB controller, which drives the inputs of the output buffers is powered from USB VBUS. If VREF is present but USB power isn't then the buffers will be powered but they should still be held in tri-state because the output enable pin is pulled to ground through a resistor. I don't think you will need to insert extra buffers between TMS, TCK, and TDI. Thanks, Michael
  2. @David Allen Wow that's a lot of multiplexers! I don't see any obvious problem with your diagram. Have you scoped JTAG_REQ_N and VPX_JTAG_EN_N to make sure that they remain stable when the daughter card is being used to access the scan chain? Btw the JTAG-SMT2-NC and JTAG-HS3 use the same USB controller... the software is almost 100 % identical so I very seriously doubt this is software related.
  3. @David Allen What type of device are you plugging into the PCB header when using Vivado? Is it a JTAG-HS3, JTAG-HS3, or something else? I assume you have 3.3V to 1.8V level translators for TMS, TDI, and TCK, and a 1.8V to 3.3V level translator going the opposite direction for TDO. Is this correct? Thanks, Michael
  4. @anshumantech 1. That proves that your HS1 and HS3 work and that the Digilent Plugin for the Xilinx tools is working. If you have access to an oscilloscope then I strongly recommend performing the scope captures that I suggested in one of my previous comments to see if we can figure out why neither the HS1 or HS3 will work with your other board. 2. The Adept GUI application and djtgcfg both support programming many different CPLD, FPGA, and Flash devices. The only combination of devices that were ever tested would be ones used on Digilent system boards, and those combinations would have only been tested on Digilent system boards and not third party boards. We never intended for the Adept GUI application or djtgcfg to be used to configure a CPLD, FPGA, or FLASH device on a third party board. For general purpose programming of series 7 or newer devices we push everyone toward Vivado and for older devices we recommend ISE 14.x. Given the confusion that this has caused for people I'm going to recommend that we either stop publishing the Adept GUI application as part of the Windows installer or that we at least note that neither the Adept GUI application or djtgcfg are recommended for use with non-Digilent system boards.
  5. @Steve Withers 1. Can you confirm whether or not you have these attached to a RoboRio? I can't tell from the angle shown in your video but doesn't look like it. 2. What are you setting the vltgRampSet field to? If it's zero then what you could be seeing is a voltage dip due to high current draw during motor start up. The default value when used in PWM mode is 1024. In can mode it gets set to whatever you pass in the control frame. 3. How often is the control frame being sent? We use a heartbeat timer as a safety mechanism. If the DMC60 doesn't get a new control command within 100ms then it will assume that the robot controller died and turn off the output. Try increasing the frequency at which you send the control frame and see if that makes a difference. Thanks, Michael
  6. @anshumantech I understand what your saying about the parallel cable but I still think there is a signal integrity issue when using the HS1 or HS3 and i've already told you how I would continue to debug this issue. Beyond that I have no further suggestions.
  7. Hi @Devendra Pundir Can you try removing U82 from your PCB and see if that solves the problem? 30pF is a lot of added capacitance for the USB data lines and is likely what's causing the issue. Thanks, Michael
  8. @anshumantech I mentioned signal integrity because iMPACT was reading different ID codes for the flash each time. If I were going to debug this I'd use an oscilloscope to observe the JTAG lines at the JTAG header with the JTAG-HS1 plugged in and do so with J13 in each of the two positions to see what the difference is. I'm not convinced it's a software issue because we thoroughly tested the ability to program an image into an XCF04S that's attached to a Spartan XC3S500E in an identical manner to what you've described and the XCF02S. I can't explain why this works with a parallel JTAG cable and not the USB cable because I don't have the schematic for the parallel cable, nor have I seen oscilloscope captures with the parallel cable vs the HS1. Thanks, Michael
  9. @ARP It's not clear to me how the map the listed functions to our API either because readmem and writemem have no meaning in the context of our JTAG API. Is there a description for how the functions you want to create are going to be used? Thanks, Michael
  10. @Lukas G We've never observed this software behavior before. I assume that you've tried closing hardware server and/or Vivado and then reopening it prior to rebooting the PC? Are you running multiple instances of Vivado to connect to these devices and program the target board? Are you using the Adept application for anything other than debugging a Vivado issue? Thanks, Michael
  11. @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
  12. @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
  13. @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
  14. @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
  15. 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