Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by malexander

  1. @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.
  2. @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
  3. @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.
  4. @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
  5. @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.
  6. 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
  7. @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
  8. @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
  9. @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
  10. @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
  11. @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
  12. @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
  13. @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
  14. 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
  15. @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
  16. @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.
  17. 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
  18. 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.
  19. @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: Thanks, Michael
  20. @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
  21. @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
  22. 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?
  23. 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.
  24. 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.
  25. Hi @Carlos Posse, Based on the output from dmesg I can tell you that this is not an issue with drivers or software configurations. It's a hardware issue of some sort. I don't see any issues with your schematic. Have you tried using a different USB cable or connecting the cable to a different port on your PC? What are you loading for L8 and L9? Perhaps try loading shunts (0 ohm resistors) instead of ferrites or inductors and see if that makes any difference. Thanks, Michael