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.
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.
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?
Am I the only one seeing these issues? Has TI tried these boards together?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
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.
In reply to Richard Prentice:
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."
Edit: Which version of the "High Speed Data Converter Pro" are you using?
In reply to dpryan:
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.
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.
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.
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).
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.
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).
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.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.