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.

DAC1282: PWDN/RESET timing

Part Number: DAC1282

I have been having an issue with the SPI interface on the DAC1282.

After some testing, it appears that the tRSTM (PWDN/RESET high to begin operation) timing parameter in the datasheet is incorrect. While I haven't fine tuned my code as yet, by observing the output of the DAC when it powers up, I suspect that this parameter is closer to 20msec, not 500nsec as shown in the datasheet.

Can someone confirm if this parameter is the same length as the power-on reset parameter, which is 2^16 fCLK periods?

Thanks,

  • Hi Andrew,

    Welcome to the TI E2E Forums!

    The reset mechanism and the power-on reset circuitry are a bit different...

    The power-on reset circuitry detects when the supply voltages have exceeded a minimum threshold and then the device is internally held in reset until the 2^16 counter has expired.

    The RESET pin, on the other hand, only triggers the the digital circuitry to reset back into a default state, and this operation shouldn't trigger the power on reset counter.


    Are you toggling the RESET pin during power-up, if so, this might not have any effect until aftre the 2^16 counter has expired?

    Also, keep in mind that the DAC1282 defaults to a very low frequency (31.25 Hz) sine wave, so perhaps it is just taking some time to see the effect of resetting the device since the output signal is slow moving.


    Best regards,
    Chris
  • Hi Chris,

    Thanks for the welcome and for getting back to me so quickly.

    I should have included a bit more information.

    Presently, we are holding the DAC in reset when we power up, and we are waiting for 100msec from power-up before we release the RESETn signal. The power supplies are stable within a few milliseconds of the power being applied, and the 4.096MHz clock is stable a few milliseconds after that.

    Initially, the code would take RESETn high and then our first access to the DAC would be 1msec after this. According to the datasheet, we should only need 500nsec between RESETn going high and CSn going low, so we were easily meeting this condition. Our first access was to read the internal registers of the DAC, however, the DOUT pin was not being driven and we got all 0's.

    We then introduced a 100msec delay between taking RESETn high and our read of the internal registers of the DAC. This now sees the DOUT pin being driven and returns the default (reset) values of all the internal registers.

    This suggests to me that we do need to delay more than 500nsec between RESETn and CSn.

    I did notice that there is around 16msec between taking RESETn high and the output starting to generate the default 31,25Hz sine wave. This is pretty close to the 2^16 fCLK period, which is why I wondered if the reset timing was the same from the RESETn signal as it is for power-up.

    It does seem that the datasheet value isn't correct, so I would be grateful for your assistance in helping us to refine our code.

    Best regards,

    Andrew

  • Hi Andrew,

    Let me check with a digital designer about this behavior... you got me wondering if perhaps the 2^16 counter isn't starting until the /RESET pin is set high.

    You could try setting /RESET high (as soon as DVDD is stable) and then toggling it after the 2^16 power on reset counter expires, and see if the device behaves differently for you, and I'll try to confirm the expected behavior on my end.

    Best regards,
    Chris
  • Hi Andrew,

    According to our designer, the power on counter should get triggered by the AVDD and DVDD supply thresholds. Holding /RESET low should have no effect on the start-up time. Nevertheless, did you try modifying your startup routine to see if you got any difference in start-up behavior?

    Best regards,
    Chris
  • Hi Chris,

    Thanks for getting back to me.

    We haven't looked at this yet, as we have been working on some other aspects of the system, waiting to see if you had any more information. I will take another look at this and make the change that you have suggested and see if we can learn anything more.

    The other thing that we might look at is pulsing the RESET pin a second time to see if the issue only exists after the initial power up.

    Best regards,

    Andrew

  • Hi Chris,

    We haven't had a chance to look at this yet, as we have been trying to keep moving forward with the other testing that we need to do for the prototype board.

    When we get a chance (which might not be for a week or two), we will take another look at this. I think it is fair to say that there is definitely an issue here, but it does require further investigation to fully understand it.

    Let me know if you find anything more.

    Best regards,

    Andrew