pull ups on DAC LDAC and CLR
Closed this issue · 22 comments
sure
added pullup
edit, wrong image
Thanks
@jordens we can solve the issue completely by allowing the CPU to turn on the output amplifier power after the DAC was properly reset/initialized. We can also add a delay to the +/-12V rail LDOs. 1s would be fine.
Moreover, the AD5542ABCPZ is unavailable. We can install AD5542ARZ which does not have CLR input. So the CPU would have to send SPI command first, then turn on the AFE supply.
Ack. Ensuring the CPU has to explicitly enable AFE power is fine. Then we also don't need the CLR input.
Even with CLR input, we must wait for the CPU to boot, then toggle the CLR H->L which takes time during which the output of the DAC is negative.
A pull up on CLR that would passively clear the DAC to mid-scale (0 V) before the CPU gets around to doing anything.
The pullup is already there for some time. It is falling edge so I'm not that sure if the issue is completely solved.
There is a power-on reset ensuring valid initial DAC register. The pull-up on CLR then prevents any LDAC/SPI activity from loading invalid shift register data into it. In that aspect CLR is level sensitive.
And AFAICT there has not been a production run with that pull up yet.
The v1.3 was produced already. Anyway, these DACs have a one-year lead time so we have to use alternatives without CLR.
So, we must keep LDAC high to make sure the random register value is not loaded to DAC and pull CLR to GND to generate H to L toggle and clear the DAC. I will also add a signal that turns the +/-12V supplies on.
Last I heard production was still being held up by various chips missing. But you know more.
Agreed. I don't think delaying the CLR assertion (by some late pulldown after an early pullup) and LDAC deassertion is necessary or useful. I'd just put the right pulldown/pullup and trust that the DAC resets itself and then ignores whatever is going on on LDAC/SPI. If in addition we have that AFE power enable (with pull-disable) then we are certainly safe.
For me, the most important thing was to patch in a pull up on !LDAC because it seemed that the DAC outputs garbage at power-reset for some time with Stabilizer v1.2 (see quartiq/stabilizer#447).
The DAC itself powers up at midscale without even reading any registers when !LDAC is high and for every state of !CLR.
This is also described in the POWER-ON RESET section of the data sheet (except the !CLR statement, but I'll come to that later).
@jordens said:
There is a power-on reset ensuring valid initial DAC register. The pull-up on CLR then prevents any LDAC/SPI activity from loading invalid shift register data into it. In that aspect CLR is level sensitive.
- you mean pull down on !CLR
- in one important detail this is not true. A pull down on !CLR results in ignoring !LDAC pulses. When !LDAC is constantly low, it just keeps the output latching and pushing out garbage on power up
@jordens said:
Ah. On CLR it should be a pull-down. Right @svrotter ?
The !CLR is edge sensitive, so pull resistors at this line in any direction won't really solve the problem. Clearing should be issued after the DAC is fully powered, which is when the pulses we were talking about already occurred.
So, we must keep LDAC high to make sure the random register value is not loaded to DAC and pull CLR to GND to generate H to L toggle and clear the DAC. I will also add a signal that turns the +/-12V supplies on.
That should be correct. I'd do the following start up sequence:
- keep !LDAC high with an external pullup
- generate a falling edge on an externally pulled up !CLR
- write valid data to the serial register (microcontroller sending midscale value)
- set an externally pulled low AFE supply enable line high
- release !CLR
- set !LDAC low
BTW: having the microcontroller to turn on the AFE explicitly is very useful in any case in my opinion.
Ok. But then 2., 5., 6. can be skipped (assuming there is a pullup on CLR). What's the point?
(2) and (5) could be skipped if there is a pull up on !CLR* !LDAC and if (3) is executed correctly. You could say that it's another level of secure start up for me.
(6) has to be executed in order to make the DAC work like it is intended right now (apply every new incoming data as soon as possible)
*EDIT: I mean !LDAC and not !CLR
The new revision has CLRn pulled low
LDAC pulled high
Assembly option with AFE power turned on by CPU by default. There is an option to remove 2 resistors and install another one and have AFE turned on automatically at the end of power-up sequence.
The new revision has CLRn pulled low
As long as !LDAC is pulled high, this works. It's basically the configuration on my patched v1.2.
If you want to clear the DAC register you just have to set it high first and then generate the falling edge with the uC.
I just experienced that you get the least problems with weird start up behaviour when these kind of lines are pulled to their inactive state (eg. active high signals have a pull down and active low signals have a pull up resistor)
Assembly option with AFE power turned on by CPU by default. There is an option to remove 2 resistors and install another one and have AFE turned on automatically at the end of power-up sequence.
Is there a missing image? If not I'm not sure whether I understand what you're referring to
Now I understand what you mean. Looks good to me