TSW1400/ADS5483 DATA CAPTURE PROBLEM

Hi

The most common cause for a timeout error is that the FPGA is not getting a clock from the data converter, which may be caused by either a misconfiguration of the ADC or the ADC EVM not getting a clock in the first place.   When the capture button is pressed, the TSW1400 FPGA will clock sample data into memory using the clock from the ADC until the requested number of samples have been caught.  If there is no clock, then the requested number of samples cannot be caught before the GUI times out.  (Although the exact wording of the error message might lead one to think the data was caught inthe DDR2 memory stick on board but timed out getting the data up to the PC.  But I dont think the error messages really make that fine a distinction on where the error might be.)

The TSW1400 has a bank of 8 LEDs on it to indicate the status of the FPGA, and one of the LEDs in the middle the bank (USER_LED3) lights when the FPGA is locked onto the LVDS data clock from the ADC EVM.  If this LED is not lit then there is no clock from the ADC to the TSW1400.

Since the ADS5483 does not have registers to be programmed through SPI and thus no SPI GUI for this EVM, then having the ADC misconfigured is not likely.  Check to see that the clock into the EVM is valid, and if it looks to be valid, then possibly check with an oscilloscope for the presence of the clock into the ADC and the presence of the clock (called DRY I believe) out of the ADC.  And of course check that the EVM has power supplied.

If one of these things do not solve the problem then we will have to dig in a little deeper and see what is gong on.

Regards,

Richard P.

Thanks for that. We found that the USER_LED3 is off meaning there is no clock coming from the ADS5483EVM. Worse than that no LEDs on the board a lit except for the power LED.

Hi,

If none of that bank of LEDs are lit then I would suspect the FPGA does not have its bit file loaded, but in that case the GUI should not let you click the capture button.  Perhaps i could see a screenshot of the HSDCPro - i would be looking for the firmware name to be visible in the lower right corner and saying ADC_BYTE_WISE_1CH as the name of the firmware loaded into the FPGA.  The user is allowing the firmware to be loaded into the FPGA after choosing the ADS5481-85 device type, I hope?

Regards,

Richard P.

With no LEDs lit on the TSW1400 except the power LED it seems that the TWS1400 is the problem. We have checked the power rails on the TSW1400: 3V3, 1V8, 2V5, 0V9, 1V1, 1V5, 3V0 and they fine. The customer is using Windows 8 could this be the problem? What else would cause the FPGA not to configure?

John,

We have not done much testing with HSDC Pro using Windows 8. Is there a way the customer could try a pc with Windows 7?

Regards,

Jim

We discussed using a PC with Windows 7. All of their computers have windows 8 so it will be difficult for them. Does the FPGA only program once HSDC Pro is running or should it program once power is applied? The TSW1400 this customer is using was used by another customer and I am trying to rule out a hardware failure.

John,

 The FPGA is programmed everytime power is applied and the GUI mentions "Downloading firmware, please wait". We have had some customers who had problems with Windows 8 and some that have not. There has only been a couple of cases that I can think of. I am guessing this is your problem.

Regards,

Jim 

Hi,

Our software development team also tells me that we have seen the HSDCPro run on a few Windows8 systems but that it has not been checked out fully.  There may be corner cases that may turn out to have an issue.

But again, may i ask that we get a screenshot of the HSDCPro when they get this error message?  We would want to see in the screenshot what the GUI thinks may be loaded for the firmware by looking at the lower right corner for the firmware name and the lower left corner for the firmware revision. 

One more thing to try in the meantime - i told you earlier what the 'name' of the firmware is for this device selection - ADC_BYTE_WISE_1CH.  There is a drop-down menu item for Download Firmware.  If they choose this menu item and then choose the firmware name ADC_BYTE_WISE_1CH does the firmware then download correctly?  (meaning that the HSDPRo shows this firmware type in the lower right and the LEDs on the hardware light up finally?) 

Regards,

Richard P.

Sorry for the delay Richard.  

Here are two screen shots.  Each with a different ADC.  I can say that the FPGA is not being configured because the LED is not on.  HSDCPro does communicate with the TSW1400.   I had the customer try to download ADC_BYTE_WISE__1CH, but LEDs on the hardware didn't light up.  Also, ADC_BYTE_WISE_1CH is not showing up in the lower right hand corner of HSDPro.  

Customer has said that they only have Windows 8 available. 

Regards,

John Wiemeyer

The customer was able to locate a Windows 7 computer.  Now with Windows 7 they are still having the same problem.  Here are the screen shots.

One more detail. In Windows 8 the customer did try loading ADC_BYTE_WISE_1CH. They continued to get the same errors as above. None of the LEDs are on TSW1400 are lit indicating that the FPGA is not being configured. What is required to load the FPGA?

I am wondering if there could be a hardware problem. This TSW1400 has been used by another customer.

Regards,
John Wiemeyer

Hi,
The capture times out because the firmware is not able to be loaded into the FPGA. The TSW1400 does not keep the bit file in an eeprom on the board for the FPGA firmware but rather gets the firmware on powerup each time from the PC. This way we can release new firmware or fix bugs without having to recall boards to reflash eeproms with new code. But sometimes the firmware loading fails . We have seen this issue arise a number of times and for various reasons. On some early TSW1400, there was a resistor installed on position R55 that shouldn't have been, but those boards should be out of circulation by now. Sometimes old USB1.0 ports would be an issue, but if it is a new PC with Windows 8 then that shoudlnt be an issue. Is this PC using a USB3.0 port? But if you found a PC with Windows 7 then that might be a USB2.0 port. In hardware device manager, does the TSW1400 USB port show up under Universal Serial Bus controllers with four entries named A, B, C and D? Or does the hardware device manager report driver problems for the four USB ports? The USB chip we used on the hardware has four ports or channels and we use one of them to mimic a JTAG port for firmware download.
I will consult with our software team, but we may have to just swap out the TSW1400 for you if we don't find some specific reason for the failure.
Regards,Richard P.

Thanks for the details Richard.   I had the customer check on the status of the USB ports and here is what they found:

As you indicated, there are 4 USB ports (A, B, C & D) showing up so this looks good.   If the customer loads a file such as "ADC_BYTE_WISE_1CH" will this initiate a FPGA load?  We have confirmed that R55 is not installed on the customer's TSW1400.   

Thanks for your help.

Regards,

John Wiemeyer. 

John,

Based the screen shots the GUI is able to connect to the USB on the TSW1400 and get the serial number for that EVM.  Thats good.  The issue seems to be that the GUI cannot access the JTAG port through the USB chip to program the firmware bit file into the FPGA.  If this doesn't happen, a capture will do nothing as there is no firmware and the GUI will time out as it is showing in your 2nd plot.  So the root of the problem is that the firmware is not being pushed into the FPGA properly.

We have had a issue in the past with one of the resistor pull downs on the verge of being too strong.  Can you confirm if the resistor R55 on the back of the board near on of the FPGA corners is installed or removed?  I would recommend removing R55.  This has helped in some cases where the JTAG port was an issue.

Ken.

Hi Ken,

As mentioned earlier we have confirmed that R55 is not installed on the customer's TSW1400. 

Regards,

John Wiemeyer.

Hi Ken,

No problem. My email address is jwiemeyer@arrow.com. Please send your email address to me.

Thanks for your help.

Regards,
John Wiemeyer

Hi Ken,

Customer looked at the High speed data pro manual, under section 3.1.2  instrument options, right at the bottom of page 10 reads

“The Download Firmware command allows the user to select a file that will be used to program the FPGA.These files need to be .rbf files for this to work”

Customer searched the directory

C:\Program Files (x86)\Texas Instruments\High Speed Data Converter Pro\1400 Details\Firmware and found the following:

The customer is using the ADS5483EVM.  Do they need the .rbf file for that EVM for the FPGA to program?

Regards,

John Wiemeyer

John,

That is an option that allows manual loading of a custom RBF.  Mostly that is used for custom or pre-released EVMs.

The process normally selects the appropriate rbf based on the device that is chosen in the drop down.  If you look in the ADC files there are a bunch of ini files that correspond to the drop down options.  If you open the ADS5481-85.ini you will see the interface name - that corresponds to the rbf that is used.  This is automatically loaded by HSDC Pro and pushed into the FPGA via JTAG.  You do not need to do anything manually.

You can try to load in any of them to see if it will work, but I think there is something wrong with the hardware as this process is done every time TSW14xx is used with HSDC Pro.

Ken

Thanks Ken!

Regards,

John Wiemeyer

Ken,

The replacement TSW1400 is working much better than the last one.   THe FPGA is being programmed.  Now the customer needs to confirm that his ADS5483EVM and TSW1400 are working together properly.   The ADS548xEVM User's Guide describes using  it with the TSW1200.  The TSW1400 User Guide describes using it with other ADC EVMs, but not the ADS5483EVM.  Is there a procedure to follow for the ADS5483EVM and TSW1400 to confirm they are working and show capture data in the frequency domain?

Thanks for your help.

Regards,

John Wiemeyer 

Hi,

No, there is not an updated document for the TSW1400 and ADS5483 combination.  The ADS5483 is one of our older devices and EVM that was created during the reign of the TSW1200.  With the TSW1200 giving way to the newer TSW1400 we have not gone back and rewritten all the older EVM User Guides.    The User Guide for the TSW1400 and HSDCPro should be all that is needed for connecting to almost all of our product portfolio, and the ADS5483 EVM does not have a GUI of its own since the ADC does not have any register programming by SPI, so there should be no substantive changes to the User Guide to cover TSW1400 captures instead of TSW1200 captures.  The screenshots of the capture would just be TSW1400 screenshots instead of TSW1200 screenshots.

Regards,

Richard P.