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.

DAC38RF89EVM: In-system programming support.

Part Number: DAC38RF89EVM

Hi, I originally opened up a TI support case, but they suggested I post this here. (Case #CS0742865)

We have purchased a total of 5 DAC38RF89EVM’s. 2 are labeled “Rev E”, and 3 are labeled “Rev F”. Two of the “Rev F” boards are now failing. They were previously working fine and have not been modified since. We modified all 5 boards for in-system programming by our host KC705 board. We’d like to run our board modifications by you to see if we did something that may have damaged the chip.

Modifications:

  • Installed 0 Ohm resistors for R288, R289, R290, R291 and removed the 4 jumpers on J23
  • Installed 0 Ohm resistors for R292, R293, R294, R295.
  • Installed 0 Ohm resistors for R9 & R10. We configure GPO0 to be the SYNC0 signal.
  • We white wire R9 to C27 so that the FPGA can control DAC_RESET. We use an open drain configuration in the FPGA for this signal.
  • We ground R177 so that JESD_TRSTB is grounded.

Both of the failing systems were previously working fine, then started showing startup failures later. On one of the failing boards, the DAC becomes extremely hot compared to the working boards. On the other failing board, register 0x7F[14:10]  (EFC_ERR) never clears after a DAC reset. Figure 142 in the data sheet tells us to check this register before programming the chip, but I don’t see much documentation on what an “EFC_ERR” indicates. If we just skip this check, the chip holds the SYNC signal low after configuration, but never raises it, even though the FPGA is transmitting the startup sequence.

We have the chip configured for 8-bit mode, sampled at 8GSPS. We’re using an external 250 MHz signal on J4 for our clock reference. The LMK chip is being configured correctly (we have blinking LEDs that show the clock is correct).

Any insight would be helpful. 

Thanks,

Jimmy Mumper

  • Jimmy,

    You should remove R183, R184, R185 and R186. Make sure you grounded the correct pad of R177 or else TRSRB will be high causing the DAC to not load the fuse farm correctly. This will also cause many errors to occur in register 0x7F bits 14:10. If the DAC is not getting a proper reset, this may also cause this issue. Make sure to issue the reset after the clocks are present and make sure the reset pulse width is per the data sheet.  Please remove R178 as this could also prevent the DAC from getting a valid reset.

    Everything else appears to be correct.

    Regards,

    Jim

  • Hi Jim,

    Thanks for the quick response. However, we're still seeing issues. It seems that the USB GPIOs come up as floating if USB is not connected, and I can read/write to the LMK chip just fine. I verified that TRSTB (both sides of R177) comes up as GND when we power the system on. I probed the positive side of C27(DAC_RESET) and it is going low for one millisecond (the datasheet says the minimum width is 10 us). We wait 1 millisecond after programming the LMK chip before we issue the DAC reset. So the clocks should be stable by then. 

    I also tried to configure the boards using the EVM GUI software and an FPGA image that tristates all SPI and reset control signals (so that the USB chip can have complete control). This method works fine on our "working" board. But still shows issues with the 2 non-working boards. So I'm fairly certain there is something wrong with each of these 2 failing boards. Here is the status of each:

    SN RF89-00533 : Using in-system programming (and no USB connected), register 0x7F returns 0x8C09 after a DAC reset. (Clocks are stable, and I’ve tried issuing multiple resets, with no luck). If I use USB to configure the system using the EVM GUI (and the FPGA image with control pins tristated), the GUI says everything configures properly, but the SYNC pin remains low forever (GPO0). The FPGA is transmitting the ILA data just fine. When I read back register 0x7F in this configuration, it returns 0x8009. So I guess something about having USB connected prevents the “FUSE FARM” errors that I’m seeing in the other configuration. However, the SYNC signal is still locked.

    SN RF89-00543 : This board works intermittently. It will transmit a signal for a few minutes, then the SYNC signal will go LOW for a bit, then the signal returns. Occasionally the board never comes out of SYNC at all. I’ve also seen a good signal for a bit, then the signal disappears, but SYNC remains high, and the FPGA is still transmitting data over JESD. The frequency of issues seem to be temperature dependent. One other unusual thing : The heat sink gets EXTREMELY hot. We are often reading 77 degrees Celsius on this heat sink. Where the other boards read somewhere between 45 and 55 degrees C.

    The changes we’ve made to these boards are pretty minimal and shouldn’t have any impact when those signals are tristated in the FPGA. We’re fairly certain there are issues with the boards we received. Is it possible to get these replaced? And if so, are there any Rev E boards in stock? It may be a coincidence, but we have not seen any issues on our Rev E boards.

    Thanks for your help,

    Jimmy

  • Jimmy,

    If you bought the boards from a distributor, you will have to work with them to get a replacement. TI authorizes that an exchange be made on the two failing units.  If you bought the boards from the TI Store, the following link has the details and a link to the form to start the return process.  Once you are on the returns and refunds page of the TI Store look for the hyperlink which says: TI store customer support form. 

    Regards,

    Jim

     

    www.ti.com/.../ti-store-order.html