• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 236 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DAC8775: Alarm Pin & Status Bit Observed Contradictions

Jason Harrington
Prodigy 50 points
Part Number: DAC8775

Tool/software:

TI,

I’ve read through the datasheet for the DAC8775, but I’m a bit confused about the behavior I’m observing. I’m using the positive buck-boost configuration with a 0–20 mA output on channel C. According to the datasheet, an open-circuit condition lasting more than 500 µs should trigger an alarm event. When I remove the load from the DAC, the ALARM pin goes low, as expected. However, when I reconnect the load, the ALARM pin returns to high (no alarm), which seems to contradict the following statement in the datasheet:

"For condition (1) mentioned above and Buck-Boost converter used to power the DAC, the ALARM pin if pulled low due to the alarm condition will remain pulled low even after the alarm condition is removed (latched behavior)." Section 8.3.8, Page 40

Is this normal?

Additionally, before the open-circuit condition is introduced, the status register at 0x0B shows no fault on channel C (value: 0x8B1380). When I introduce the open, the fault bit for channel C is set (value: 0x8B1384), as expected. After I reconnect the load, the fault bit remains set—which still agrees with the datasheet behavior, although the ALARM pin returns to high. I’ve attempted to clear the fault by writing a ‘1’ to the corresponding bit (0x0B1384), but it doesn’t clear.

Even though the observed ALARM pin behavior isn't am issue for me, it still seems inconsistent with the datasheet. Also, the inability to clear the status register bit by writing a ‘1’ contradicts the datasheet’s instruction:

"Whenever one of these status bits is set, it remains set until the user clears it by writing '1' to the corresponding bit on address 0x0B." Section 8.3.10, Page 41

Any advice would be greatly appreciated.

Thanks,

Jason Harrington

  • 0
    TI__Guru* 97585 points

    Jason,

    Give me a little time to look at this. I might not be able to get an answer to you until tomorrow or next week. 

    Are you testing this with the DAC8775EVM and the GUI? or are you using your own software/digital connections?

    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 50 points

    Hey Joseph!

    Thanks for your reply, I am using the DAC8775EVM with my own code. With the exception of the status and Alarm behavior mentioned in this post, everything else has been working flawlessly. I have been able to enable and disable the DAC as well as read and write various parameters. I should point out that I am using the DAC with CRC enabled, but I haven't noticed any faults reported on the status register. I wouldn't think that would make a difference, nut I thought I would mention it.

    Thanks,

    Jason

  • 0 in reply to Jason Harrington
    TI__Guru* 97585 points

    Jason,


    I was able to test this and it does look like the ALARM pin is returned high as soon as the fault is removed. I'll need to look at this a bit more, but I did try couple of different cases for the alarm actions just to see if that would affect it. Regardless of setting, once I open the output in IOUT mode, I see the ALARM go back high when the load is returned.

    As an example, I used the B channel and pulled out the load jumper on the EVM. I can see that the FAULT pin goes low as a result and goes high once I replace the jumper. After that I check the 0x0B register for the STATUS, and see that the FB bit has flipped so that the register now reads 1002. Note, I was able to clear the register by writing a 1 to the bit. In that case, I wrote 0x0002 to the register and that cleared the fault.

    I'll take a longer look at it later, but I does look like the ALARM pin isn't sticky, while the fault bit is sticky. Again, I was able clear the register by writing a 1 to the faulted bit.


    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 50 points

    Joseph,

    Thanks for confirming the behavior that I observed. I was able to clear the bit when I had CRC disabled, however when CRC is enabled, I was unable to get it to work. Is it possible that for some reason the status fault reset doesn't work with CRC enabled? With the jumper on channel B removed and then replaced, which creates the fault condition, similar to what you generated, I write 0x0B0002E2. Are you able to confirm if my CRC is correct? I would be surprised if it isn't given that everything else works as intended.

    Thanks 

    Jason

  • 0 in reply to Jason Harrington
    TI__Guru* 97585 points

    Jason,

    For the transmission, 0x0B0002E2 would be the data I expect would be transmitted. I'll need some time to check this. I'm not sure I have the ability to send and receive CRC with this GUI. I might be able to put something else together, but it might take a little time.

    Joseph Wu

  • 0 in reply to Joseph Wu
    TI__Guru* 97585 points

    Jason,

    Sorry I haven't had a chance to work on this lately, but I should have some time coming up. Let me know if you're still seeing this issue.

    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 50 points

    Joseph,

    Thanks for checking in. I appreciate that you are still trying to resolve my issue. Fortunately, in 0-20 mA mode, the fault flag hasn't caused any issues for me. With the exception of not knowing if the load has been disconnected, I am able to use the DAC as intended.

    -Jason

  • 0 in reply to Jason Harrington
    TI__Guru* 97585 points

    Jason,

    I did finally have a chance to check this. I was able to clear the alarm with an extra step but I'm not sure why it worked. Here's the process I used to setup the DAC8775. The lines use the notation for setting up the SPI in my USB device.

    SPI CH1 BREH L 0x02 0x00 0x11 H Check reference high
    SPI CH1 BREH L 0x06 0x00 0x0F H Select BB
    SPI CH1 BREH L 0x07 0x00 0x03 H Enable BB both high and low, check BB
    SPI CH1 BREH L 0x03 0x00 0x28 H Select DAC, CRC enable
    SPI CH1 BREH L 0x04 0x10 0x05 0xE7 H Enable DAC, set range
    SPI CH1 BREH L 0x05 0x10 0x00 0x97 H DAC output 1.25mA, check loaded output
    SPI CH1 BREL L 0x8B 0x00 0x00 0xE7 H L R R R R H Read status, should be clear of alarms
    Check alarm, should be high
    Pull out load
    Alarm should be high
    SPI CH1 BREL L 0x8B 0x00 0x00 0xE7 H L R R R R H Read status, should alarm for output A (0x0001)
    Replace load
    Alarm should go low
    SPI CH1 BREL L 0x8B 0x00 0x00 0xE7 H L R R R R H Read status, Read status, should still have alarm in status
    SPI CH1 BREH L 0x0B 0x00 0x01 0xEB H
    SPI CH1 BREL L 0x8B 0x00 0x00 0xE7 H L R R R R H Read status, Read status, alarm in status should be cleared

    So for this sequence, it should have cleared the alarm bit at the LSB (representing channel A) but it didn't clear. Only after I wrote the clearing command twice did it properly clear. This would be a write to the SPI of 0x0B0001EB (EB is the CRC) written twice

    Using that, it cleared correctly. Without the double write, it didn't. I'll check with the design team as to why this might be, but for now, it seems that this would work to properly clear the alarm condition from the status register.

    Joseph Wu