Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


malexander last won the day on November 21

malexander had the most liked content!

About malexander

  • Rank
    Prolific Poster

Profile Information

  • Gender

Recent Profile Visitors

2184 profile views
  1. 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
  2. @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
  3. @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
  4. @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
  5. @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
  6. @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
  7. @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
  8. @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
  9. 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
  10. @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
  11. @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.
  12. 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
  13. 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.
  14. @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
  15. @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