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 - possible SWIF interface problems

Other Parts Discussed in Thread: DAC161P997

My circuit is a copy of the reference design of the DAC161P997 evaluation board with a few things removed/changed to save cost.

I'm using the simplex configuration with an isolation transformer. That all seems to be working just fine. DIN and DBACK are transitioning as documented in the data sheet SWIF frame protocol. I'm sending frames in continuous mode D:0:(15 bits):P1:P0:D.....

ERRB is solid low indicating some sort of error condition.

SWIF interface is using a 525 Hz bit rate so the 1/4 bit transitions are occurring every 476 uS. Data sheet states minimum rate is 300 Hz so this meets spec. I have verified the signal timing and transitions using a scope to make sure the timing is rock solid and does not move out of the required timing ranges. I had to do a little software algorithm changing to get the 1/4 bit transitions at a very tight regular period. That is all very solid now. Also verified the start up sequence and that looks good. Starts up with a D symbol and then starts a frame with another D symbol. So 2 D symbols are sent about 100mS after power on.

Low voltage power supply is 3.3V and loop current power supply is 24V.

Example bit pattern being sent to device via SWIF

4000 uA (0x2AAA)

D:0:0:0:1:0:1:0:1:0:1:0:1:0:1:0:1:0:1:0:1:0:D

P1 = 1 (3 bits are 1 in TAG and MSB)

P0 = 0 (4 bits are 1 in LSB)

I can send schematics via e-mail if you need them. Cannot post here for obvious reasons.

I can get scope trace of DIN DBACK if you need them.

  • One other note:

    Device has a current output of 3.373 mA all the time I'm sending frames. This is the ERR_LOW value. High voltage and low voltage power supplies are stable.

  • I found the problem. Pilot error here. I did not read the data sheet exactly and have the parity reversed. I discovered this by changing my algorithm to put the ACK period in the frame and did not see an ACK.

    D:0:0:0:1:0:1:0:1:0:1:0:1:0:1:0:1:0:1:0:1:0:D:A:A

    Then I read the data sheet again and noticed that the parity calculation includes an '== 0' what basically inverts the parity. I originally just had the sum of 1s mod 2.

    I also added a configuration register write phase in the beginning so all is not lost. Now I can write configuration registers and I have the ACK phase in there so I can at least check the ACK with a scope.

  • Great! 

    Thanks for the feedback and I'm happy to hear that you resolved the problem!