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

DAC161P997: Error reporting issues

Sharada Balaji
Prodigy 30 points
Part Number: DAC161P997

Hello,

The datasheet for this part says the OUT pin is taken to its ERRB state when one of a few types of errors occurs, if the Threshold number of errors occurs in a row. If there are singular errors, for example with parity or frame length, does the OUT pin stay at the last known "good" output or does it go to the newer "bad" output, whatever it is interpreted as? 

I have a setup where Thresh is set to 16, and only Frame and Parity error reporting is enabled. It works fine except in specific cases, where it seems like the bit lengths get corrupted by other interrupts in the system. When this happens, the DAC output dips briefly to a lower value (e.g. if it drops to 1/2 the value, I think it means the MSB got corrupted and a bit that should have been a 1 went to 0). Because Thresh is high, the ERRB level isn't reached. I know the actual data being sent is correct. By turning Thresh to 1 and leaving error reporting on, I can see that the DAC sees these dips as errors. Should it be showing the "bad" data as well, or is something else going on? 

Thank you,

Sharada

  • 0
    TI__Expert 5820 points
    Hi Sharada,

    The output current during an channel, parity, and frame errors is set by the ERRLVL pin. When the fault condition occurs the loop current will be one of the error levels but when the fault is removed the current will return to the value previously set by the DAC code.

    What do you have ERRLVL connected to? What could be happening is the output is dropping to ERR_LOW because a frame error occurs but then is corrected so returns to the previous value. This could appear as a temporary drop in output current as you describe.

    Thanks,
    Garrett
  • 0 in reply to Garrett Satterfield
    Prodigy 30 points

    Hi Garrett,

    The ERRLVL pin is at 0 and the error current is the default ERR_LOW, 3.375mA. I see this error current frequently when I have error reporting enabled, and the threshold set to 0. 

    However, I can also see drops to a different current, generally ~1/2 of the setpoint current (which is much higher than 3.375mA). It's these other drops that are suspicious, because the DAC sometimes recognizes the error (there is a drop to 3.375mA), but also seems to output the error-ed data. From what you said, this isn't usual behaviour for the DAC, so I think it's fair to assume that the data from my side is being corrupted to the point that it appears as usable data to the DAC. I will work on the timing of data bits from my end. 

    Thanks,
    Sharada

  • 0 in reply to Sharada Balaji
    TI__Expert 5820 points

    Hi Sharada,

    If all of the error reporting is disabled do you still see this drop to ~1/2 of the setpoint?

    If so, this is likely a symbol timing issue which may cause the incorrect data being latched into the DAC. The symbols are based on the duty cycle of the input waveform. The easiest way to identify the issue is to monitor DIN, ACKB, ERRB and the output (voltage across the load) on a single scope plot when this current drop occurs. Any timing issues should be visible in the DIN waveform. Can you provide this?

    Thanks,
    Garrett

  • 0 in reply to Garrett Satterfield
    TI__Expert 5820 points
    Hi Sharada,

    Any update on this thread?

    Thanks,
    Garrett
  • 0 in reply to Garrett Satterfield
    Prodigy 30 points

    Hi Garrett,

    Sorry for the delay. It turns out that it was indeed timing, since slowing down the bit rate resulted in fewer dropouts. I imagine the other system interrupts no longer corrupt the data being sent because the tolerances on each bit for the DAC data are higher at a slower bit rate.

    I didn't capture any oscilloscope plots, but this seems to be a fix for the issue. 

    Thanks,
    Sharada