• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 46 subscribers
  • Views 390 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.

DAC3282 startup issue

Stefan von der Mark1
Prodigy 40 points
Other Parts Discussed in Thread: DAC3282

Hi,

We are using a DAC3282, connected to an Virtex-5 FX70T which provides the multiplexed data at 245MSPS via an OSERDES. This usually works fine, but sometimes the data gets messed up. If this happens, it happens right after power up and will stay like that until the next power cycle. Therefore I assume something is wrong with the power up sequence. However, I do follow exactly the startup sequence as recommended in the datasheet. Any ideas?

Details on our setup:

- Virtex-5 FX70T on an Avnet Mini Module Plus
- Both channels (A and B) are used
- Data rate 245 MSPS
- Sampling rate 490 MSPS (2x interpolation mode)
- 245 MHz Data clock and 490 MHz sample clock are generated by a CDCE72010, the data clock runs through the FPGA (an ODDR creates the clk signal for the DAC)
- the sample clock runs directly from the CDCE to the DAC (dual clk mode)
- FIFO is enabled in the DAC


Any ideas would be appreciated!
Stefan

  • 0
    TI__Guru 65864 points

    Hi,

    Could you post your register settings and start-up sequence? This may help with the debugging.

    Please also read back CONFIG7 alarm register to narrow down the issue. You will need to clear the register first by writing all zeroes, and then read back the register for the latest status. This will help us narrow down the issue.

    You may also want to check if you have initialized the clock divider correctly at start-up. This circuit generates the divided down clock for the internal logics, and requires initialization along with the FIFO at start-up. To enable clock divider sync, set bit1 of CONFIG18 to 1. The clock divider will look for synchronization signal at either ISTR or OSTR pin, determined by multi-sync_sel bit at CONFIG19.

    To ensure there are no bit errors at the data input side, you could run the input data pattern checker. The description and setup are described on page 35 of the datasheet. You may want to try this to make sure the data from the FPGA does not have issue at start-up.

    -KH

  • 0 in reply to Kang Hsia
    Prodigy 40 points

    Hi,

    I have tried the clk_syn but not seen any imporvements.

    However, I have now seen that bits get interchanged between channel A and B (i.e., while channel B should receive all 0, there is output signal when I send data to channel A). Can this possibly happen by FIFO or clk_sync issues, or is this proof that the issue is in the FPGA?

    My FPGA design does not allow to send arbitrary data to the DAC, therefore I cannot use the pattern checker.

    Thanks,

    Stefan

  • 0 in reply to Stefan von der Mark1
    TI__Guru 65864 points

    Stefan,

    This sounds like the FRAME signal to the DAC3282 has shifted over various power cycles.

    The purpose of the FRAME signal is to register the upper 8 bits of Channel A data and load them into the FIFO. The FIFO can then align the rest of the data in order: i.e. upper 8 bits of A, lower 8 bits of A, upper 8 bits of B, lower 8 bits of B. See FIg 34 of datasheet for detail. 

    If the FRAME signal has shifted, it is possible that the FRAME has grouped the data format starting with upper 8 bits of B. (Basically, the DAC cannot distinguish the difference between upper 8 bits of A and upper 8 bits of B since they are both aligned to the rising edge of DATACLK, unless the FRAME signal indicates the start of the pattern). 

    It is possible that the FIFO and clock divider of the DAC are synchronized correctly, but the data order is disrupted. 

    -KH

  • 0 in reply to Kang Hsia
    Prodigy 40 points

    Hi KH,

    I had seem FRAME issues earlier, but then channel A and B were exchanged altogether (this had been a startup issue in the FPGA and is fixed now).

    What I had seen last week was, that only the MSB of chan A showed up as LSB of chan B and vice versa.

    I found one point where I violated the recommended power up sequence: I applied the LVDS signals (including DATACLK and FRAME) before taking the DAC3282 out of reset. I changed that, and now it seems to work (cannot be sure, though, as it has always been an infrequent error). However, I still sometimes see error "32" (FIFO collision) in the status register 0x07. I read this register several times during the power up sequence (setting it to 0 after every read). Sometimes the status is 32 after coming out of reset, and is 0 after FIFO reset (how it should be). But sometimes it is the other way round, too. If it is 32 after disabling FIFO reset, it will read 32 repeatedly, however, the device works fine. Is this a problem?

    My complete startup sequence now is:

    - During power up nReset and TXENABLE are both low (i.e., Reset is enabled and TX is disabled).
    - DACCLK starts (power up of the CDCE), (DATACLK and FRAME also start during power-up of FPGA)
    - some seconds later (CPU is booting etc.):
    - LVDS is reset, DATACLK and FRAME are stopped
    - DAC nReset goes high
    - SPI interface is initialized [ write 0x04 to 0x17: set Interface to 4 wire ]
    - LVDS is started (DATACLK, FRAME and DATA (all 0) start simultaneously)
    - write(0x07, 0x00); // clear error register
    - read(0x07, &status); // #1
    - write(0x00, 0x50); // disable FIFO reset
    - write(0x01, 0x10); // offset binary;
    - write(0x07, 0x00); // clear error register
    - read(0x07, &status); // #2
    - set TXENABLE
    - write(0x07, 0x00); // clear error register
    - read(0x07, &status); // #3
    - write(0x07, 0x00); // clear error register
    - read(0x07, &status); // #4

    The status read #1 will sometimes be 32 and sometimes 0, but this should not be critical I think.

    However, #2, #3 and #4 also sometimes read 32 as I said above, at a single startup sequence I always get the same reading for #2,#3,#4. The DAC still works, however I think something is wrong here?

    Previously I had tried to sync the clks via

    - write(0x13, 0x02); // sync clk dividers on FRAME
    - write(0x12, 0x00); // disable clk divider syncing

    but doing this I got worse results (more frequent failed startups), therefore I removed this code again.

    Thanks for any hints,

    Stefan



  • 0 in reply to Stefan von der Mark1
    TI__Guru 65864 points

    Hi Stefan,

    Please see my answer in red. You may also check out the application note: http://www.ti.com/litv/pdf/slaa584 for details related to DAC3282 synchronization. 

    I had seem FRAME issues earlier, but then channel A and B were exchanged altogether (this had been a startup issue in the FPGA and is fixed now).

    What I had seen last week was, that only the MSB of chan A showed up as LSB of chan B and vice versa.

    KH: this seems to be some sort of bit error. Could somehow the DATACLK or the DATA shifted over time and over power up cycle?

    I found one point where I violated the recommended power up sequence: I applied the LVDS signals (including DATACLK and FRAME) before taking the DAC3282 out of reset. I changed that, and now it seems to work (cannot be sure, though, as it has always been an infrequent error). However, I still sometimes see error "32" (FIFO collision) in the status register 0x07. I read this register several times during the power up sequence (setting it to 0 after every read). Sometimes the status is 32 after coming out of reset, and is 0 after FIFO reset (how it should be). But sometimes it is the other way round, too. If it is 32 after disabling FIFO reset, it will read 32 repeatedly, however, the device works fine. Is this a problem?

    KH: the FIFO alarm warning is to inform you that the FIFO may be on the boundary of collision. Any shift in clocks (either DATACLK or DACCLK) could cause the collision and errors. Is there anyway that you can resynchronize the FIFO after encountering FIFO collision alarm?

    My complete startup sequence now is:

    Please see if the my suggested start-up sequence helps

    - During power up nReset and TXENABLE are both low (i.e., Reset is enabled and TX is disabled).
    - DACCLK starts (power up of the CDCE), (DATACLK and FRAME also start during power-up of FPGA)
    - some seconds later (CPU is booting etc.):
    - LVDS is reset, DATACLK and FRAME are stopped
    - DAC nReset goes high
    - SPI interface is initialized [ write 0x04 to 0x17: set Interface to 4 wire ]

    - write(0x01, 0x10); // offset binary; KH: offset binary can be part of the SPI interface. 

    KH: enable clock divider sync here:

     - write 0x13 = 0x02 (FIFO read pointer and clock divider reset through FRAME)

     - write 0x12 = 0x02 (enable clock divider sync)

    - LVDS is started (DATACLK, FRAME and DATA (all 0) start simultaneously)
    - write(0x07, 0x00); // clear error register
    - read(0x07, &status); // #1

    KH: resync FIFO and clock divider if needed at this step, check alarm again. 
    - write(0x00, 0x50); // disable FIFO reset

    - write(0x12, 0x00); //disable clock div sync

    KH: once the alarms are cleared, start transmission. 

    - set TXENABLE

    The status read #1 will sometimes be 32 and sometimes 0, but this should not be critical I think.

    However, #2, #3 and #4 also sometimes read 32 as I said above, at a single startup sequence I always get the same reading for #2,#3,#4. The DAC still works, however I think something is wrong here?

    Previously I had tried to sync the clks via

    - write(0x13, 0x02); // sync clk dividers on FRAME
    - write(0x12, 0x00); // disable clk divider syncing

    but doing this I got worse results (more frequent failed startups), therefore I removed this code again.

    Thanks for any hints,

    Stefan