• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 46 subscribers
  • Views 1544 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS548xEVM with TSW1400

David Ryan
Intellectual 295 points

Are there any instructions for using the ADS548xEVM with the TSW1400 host board?

The instructions that I could find were all for the obsolete 1200 board.

I managed to get things working, but I'm not sure if I did it right.

  1. Hardware mod: Bend J13 header on the ADS548xEVM board to a right angle (or at least ~45deg) so that the two boards can mate.
  2. Use the default jumper configuration. I added J11 2-3, but I don't think it matters.
  3. Apply +5.2V to J5 (draws 620mA)
  4. Apply 1.5Vpp 30MHz sine wave to J12 CLKIN. (I don't have an arbitrary waveform generator that goes higher in frequency.)
  5. Open High Speed Data Converter Pro v2.00
    1. Connect to the TSW1400 board.
    2. Click on "Select ADC" dropdown and choose ADS5481-85.
    3. Select Yes to update the ADC firmware
    4. Wait ~15 seconds for the LEDs to light up on the TSW1400 board. (All of the USER_LEDs are lit except for USER_LED4).
    5. Since the software is stuck on "Downloading Firmware", open windows task manager and kill the "High Speed Data Converter Pro.exe" process.
      1. This will close the GUI, but there is no way to close the task completely without rebooting
  6. (AGAIN) Open High Speed Data Converter Pro v2.00
    1. You will get a "No board connected" message.
    2. Unplug and replug the USB cable (Do not power cycle or you will have to start over with Step 5.)
    3. Instrument Options>Connect To Board
    4. Make sure the correct ADC is selected in the drop down (Do not update the ADC firmware or you will have to continue with Step 5d.)
    5. Set Fs to 30M (or whatever your clk frequency is).
    6. Capture should now work!

    Am I doing this correctly? I seems like I shouldn't have to force-close the program in order to get things working.

    Just a side note: I find it scary that the silkscreen says 6-36V on J5, when the default jumper configuration would cause this voltage to fry the board.
    Maybe have separate input power jacks that are properly labeled (+5V and +6-36V) if you want to provide the ability to skip the converters?

    Thanks,
    David

    • 0
      Intellectual 295 points

      Am I the only one seeing these issues? Has TI tried these boards together?

      -David

    • 0
      TI__Mastermind 29220 points

      Hi,

      I just got an ADS548x EVM to connect up to my TSW1400.

      You are right about the J13 header being in the way.  The ADS548x EVM was created long before there was the TSW1400, and the TSW1400 has to try to stay out of the keep-out zones for a lot of different EVMs and for the ADS548x there is the jumper there in the way.  The older TSW1200 was narrower and so the jumper wasn't an issue.  With the TSW1400 it is.

      Also - you are right that the silkscreen for the power input can be misleading for the *default* power supply option.  There is the *option* of using a switching power supply to take some input voltage as high as 36V down to an intermediate voltage adn then an LDO to generate the 5V and 3.3V needed on the board.  But the default option is to bypass these regulators and just run the EVM off of the 5V input.  The User Guide spells this out, but I would hope that people don't apply 36V before reading the User Guide.

      I did not have any issue with downloading the firmware the first time I selected the ADC from the drop down list.  When it asked if I wanted to update firmware (which simply means loading the FPGA bit file into the FPGA) and I said yes, the firmware downloaded and the capture worked well right away.  But some people have been having some trouble with the USB link between the TSW1400 and the PC.  In your case, i'd like to ask a few questions to maybe home in on what the issue might be.  What Windows operating system are you using?  I am guessing Windows7 or XP, and either should be fine.  Can you try other USB ports on the PC, such as a USB port on the backside of the PC if you happen to be using one on on the front panel?  And finally, could you look at the *bottom* side of your TSW1400 and see if there is a resistor installed on R55 or is that resistor footprint open?  It should not have a resistor there, but some TSW1400 have gone out with a resistor installed there and it may degrade the signal quality of the signals pushing the bit file into the FPGA.  If the resistor R55 is installed, you may remove it or you may have us remove it and try again.    The firmware download is supposed to be a short, smooth painless operation. 

      Regards,

      Richard P.

    • 0 in reply to Richard Prentice
      Intellectual 295 points

      Hi Richard. Thanks for the response.

      I'm running Windows 7 x64 and R55=NoPop. Changing USB ports (from USB hub to direct PC connection) made no difference - same steps occurred in my original post (including not finding the board after force-closing the application unless I unplug and replug the USB).

      As I mentioned, I can get the firmware downloaded (a bunch of green LEDs turn on after ~15 seconds, including FPGA_CONF_DONE).
      However, the GUI is stuck on this screen indefinitely:

      I've left it alone for 30+ minutes and it remains stuck. However, after the LEDs turn green, I can force-close and follow the steps in my original post in order to capture data on my second launch of the "High Speed Data Converter Pro."

      -David

      Edit: Which version of the "High Speed Data Converter Pro" are you using?

    • 0 in reply to David Ryan
      Intellectual 295 points

      Also, it seems like the TSW1400 is transferring data to the computer extremely slowly. I've captured ~17.476 seconds of data at 30MSps (=500Mebi samples).
      If the GUI continues at the current speed, it will take ~1 hour to transfer the data to the computer. Is this normal?

      That speed works out to only ~340kBps.

      -David

      Edit: Now it seems like there is some weirdness with the data now that (most of it) is in the computer. Seems to be "flat lining" after 250 million samples:

      Also, my screencap "so happened" to capture this in the bottom status bar:

      Edit 2: Fixed images.

    • 0 in reply to David Ryan
      TI__Mastermind 29220 points

      I have asked our software development team about the issue of the GUI getting hung up on the firmware download.  I am told that we had seen something like this happen once but could not replicate and thus could not debug.  if you would be willing, I would suggest an on-line session between your computer and our software people by either Webex or remote login so that out software team could try to look at what is happening.

      One other thing that has on occasion caused firmware download issues has been a power supply to the TSW1400 that has too low a current rating.  What is the rated current on the power module you are using?

      The very slow data capture sounds like the USB port on your PC is not a USB 2.0 port.  The older USB 1.0 ports can take a long time for a large capture.  There is i think a factor of 10 difference in speed, and some PCs that have USB2.0 in the back of the chassis might only offer USB1.0 out the front.  Could you please check the type of USB port in use.

      I have not done a 500M capture lately, so i will try that out next on my PC with my capture card and EVM.

      Regards,

      Richard P.

    • 0 in reply to Richard Prentice
      Intellectual 295 points

      I don't think there is any way for you to remote in, and I'm not sure you'd gain anything from a Webex, as I've already performed a screenshot of the "downloading firmware" message. I can get you any additional files that you need.

      For example, this was in the %temp% directory:

      High Speed Data Converter Pro_32_10.0.1f4_dpryan_cur.txt
      ####
      #Date: Tue, Apr 30, 2013 2:55:54 PM
      #OSName: Windows 7 Enterprise
      #OSVers: 6.1
      #OSBuild: 7600
      #AppName: High Speed Data Converter Pro
      #Version: 10.0.1f4 32-bit
      #AppKind: AppLib
      #AppModDate: 12/18/2012 15:41 GMT
      #LabVIEW Base Address: 0x30000000

      (There might be some other rsc or tmp files of interest.)

      I'm aware of the differences between USB 1.0/USB 2.0 "Full Speed" (12Mbps) and USB 2.0 "High Speed" (480Mbps). I don't think there are any computers built in the last 10 years that only have the former.

      However, it could be true that you guys are not using the bulk transfer mechanisms of the FTDI FT4232H to utilize USB 2.0 High Speed.
      I'd be interested to hear the results of your 500MSample speed test.

      -David

      Edit: I'm using the power supply that came with the TSW1400 (5V, 3Amps). But as I mentioned before, the TSW1400 firmware programs fine. It's the GUI software that gets stuck and requires a force close. The firmware remains programmed and I can then use the board (if I don't get the GUI stuck by trying to reprogram the firmware again).

    • 0 in reply to David Ryan
      TI__Mastermind 29220 points

      Hi,

      I spoke with our software lead about how to proceed with debug of the firmware hang issue.  I suggested maybe a webex so he could look at hardware device manager or whatever else he might think would help.  But you may be right that there would be limited utility in that for him.  What he could do is to create some extra debug code or debug utilities to run with your HSDC Pro GUI to give more insight into what is going on when the firmware download hangs up.  If at all possible I would like to see the root cause identified and fixed because it has been my experience that these things don't just go away - sooner or later there will be other people that see the issue.  But it is hard to debug when we don't have a PC in house that will exhibit this issue for us.  But we think we may have seen this happen once before so we are off looking for that machine to see if we can replicate it.  If we can replicate the issue here then we can work on it without trying to drag your machine into it.  (just before posting this update - we think we have a machine here that we can replicate the issue on.  So we will work on that.)

      I set up the ADS548x EVM again and set it for max capture depth.  1) it does take nearly an hour on my laptop to download the entire 1GByte of data.  On the FTDI4232 we are using all four ports of the device for one thing or another.  One port is just for writing register-mapped commands to the FPGA to set up for a capture.  Another is used for pushing the bit file into the FPGA.  Two of the ports on the FT device have hardware assist for SPI accesses and we *are* using these two ports in tandem to move the captured data from the FPGA up to the PC.  Yet a full capture buffer takes about an hour to upload.  It was about half that time in early development of the GUI, but I am told we cut the speed of the SPI accesses between the FT4232 and FPGA to 15MHz based on a max speed recommendation from FTDI.   (Most of our work with the capture card has been doing FFT analysis on 64Ksample captures, which takes only a second or so.)

      Finally, on a capture of 536870912 samples (1/2 GByte) i also saw only the first 268435456 samples (1/4 GByte) be valid.  When I look into the ini file for that device I see a line entry that tells the GUI that every other sample in memory is valid and every other sample is discarded.  So when the firmware was written, the author of the firmware was wasteful of memory for this data format and only used half of the available DDR memory.  So a practical limit on capture depth for this EVM is 1/4GSample without a firmware re-write.

      Regards,

      Richard P.

    • 0 in reply to Richard Prentice
      Intellectual 295 points

      Hi Richard,

      Thanks for your detailed response. I'm guessing the memory utilization is an artifact of creating the "ADC_BYTE_WISE_1CH" firmware by doing some quick modifications to the "ADC_BYTE_WISE_2CH." As a result, using a single channel ADC only lets you utilize half of the on-board RAM. I see what you're saying about the the ini file: "Channel Pattern=1,0" equates to throwing away every other sample.

      Also, I think there might be a mistake in your numbers. Below is my proposed correction:
      (Note: I'm using/abusing the IEC standard for binary prefixes... Gi (gibi-) means 2^30.)
      I think you are saying that you tried a capture of 536870912 samples (1GiB, 0.5GiSample) and only saw the first 268435456 samples (0.5GiB, 0.25GiSample) to be valid.
      As you (correctly) stated, it seems the max capture depth is 0.25GiSample.

      Thanks for all your help...

      I can live with the 0.25GiSample/~30 minute transfer for my testing; thanks for clearing up the limitations there.
      Let me know about the GUI fix (and/or if you need me to test a new release).

      -David

      Edit: Formatting

    • 0 in reply to David Ryan
      TI__Mastermind 29220 points

      Hi,

      We do have an update to your HSDC Pro GUI that should fix the issue of getting hung on firmware download.  We did find one PC in one of our labs that would hang up in that manner.  The attached dll files cleared the issue on that machine, although the root cause is I think not completely understood.  There were two calls to the FT dll after the firmware download (that had to do with purge and reset), and when we removed these dll calls the issue cleared.  But these calls should not cause a problem in the first place.  And they were put in early in the project development to clear a different issue.  But I think we have newer FT drivers now, so these two dll calls seem not to be needed.

      In the attached zip file are files TSW1400Board_CLib.abc and TSW1400Board_CLib_1.0.abc.  The file extensions were changed from .dll to be .abc so that they would not be removed as potentially malicious software.  You would need to rename them back to have the .dll file extension.  and then copy them into location C:\Program Files (x86)\Texas Instruments\High Speed Data Converter Pro\1400 Details    in place of the two files that are already there by that name.

      We constructed the HSDC Pro GUI to do the actual User Interface in Labview, but we partitioned all the low level code that accesses the FPGA into a C-code dll.  So we can make changes like this without having to do a complete re-install.  Just replace the .dll files.  You might want to keep the existing 'dll files by renaming them to some other file extension such as .old in case the new dlls don't work and you need to return to the original installation.

      Please give these two .dll files a try and let us know if it clears the issue of the GUI getting hung up, and that there isn't some issue arising instead.  These new .dll files work on our machines and clear the issue on the one machine that would hang up - but we don't have access to a lot of PCs that exhibit the issue to have full confidence in the fix at this time.

      Regards,

      RIchard P. 

       

      TSW1400 DLL files.zip
    • 0 in reply to Richard Prentice
      TI__Mastermind 29220 points

      Hi,

      i just received this update from the software team.  The dll files that I attached earlier need the latest GUI revision.   We released version 2.1 of the HSDC Pro GUI to the TI web last week, and that included updates to the dll files.  So when they were debugging the issue of the firmware download hanging up, they were doing the debug with version 2.1.  I was just told that if you are running version 2.0 or earlier, then the dll files I attached would not work anyway.  They ask would you please uninstall your version and install 2.1 from the TI web if you have not already, and *then* try the new dll files.

      Thanks,

      Richard P.

    • 0 in reply to Richard Prentice
      Intellectual 295 points

      Hi Richard,

      Sorry it took so long to get back to you, but it seems that v2.1 did not work by itself; the GUI still hangs.

      However, patching the dll's with the ones attached to your post fixed the problem for me.

      Thanks,
      David

    • 0 in reply to David Ryan
      TI__Mastermind 29220 points

      Hi,

      Thanks for letting me know that the new dll's did fix the firmware download hangup (after moving to the latest version 2.1).  i have passed this information back to the software design team.

      Regards,

      RIchard P.