DAC8750: The event occurring both alarm set and data send at the same time

Hi Yoshikazu-san,

Can the customer be more specific with the situation?

The ALARM is being triggered and going low at the same time as a register write?
Can the customer provide the attempted register write and the faulty write that occurs?

Thanks,
Lucas

Lucas-san,

Thank you very much for your quick reply.  It seems the issue occurs like this.

Alarm goes low and data is sent at the same time

-> An unexpected register write occurs

-> DAC8750 shows unexpected behaviors 

I'm asking these, but do you have any other things you'd like to check?

1. How long overlap time it needs to have between the alarm goes low and data send?

   (Does it have to be exactly the same or the data is sent a few us before/after alarm going low?)

2. How does DAC8750 behave when the issue occurs?

3. Which registers are affected by the issue?  Are these the same all the time?

4. What kind of data are written accidently?

5. Would you please provide the register dump before/after the issue?

Best Regards,

Yoshikazu Kawasaki

Hello Lucas-san,

I got answers for the questions I asked as shown below.  Would you please tell me if you need more information?

1. How long overlap time it needs to have between the alarm goes low and data send?

   (Does it have to be exactly the same or the data is sent a few us before/after alarm going low?)

(Ans)They don't know this.  Actually there is no way to check the overlap time because they don't have TP for ALARM pin on their system.

2. How does DAC8750 behave when the issue occurs?

(Ans)There are 3 behaviors on IOUT when the issue occurs, unstable(up/down) zero point, dropping gain or both of these.  The issue can occur in just 30-60 minutes, but it usually does in 3-5 hours.  The communication cycle is 50 times per second.  In normal case, it is expected to have 24 clocks to access registers as shown below left, but if the issue occurs, the clock stops working in the middle as shown below right when the interrupt is triggered.

3. Which registers are affected by the issue?  Are these the same all the time?

(Ans)From the above #2, they only monitor config, gain and zero registers which would have been written data unexpectedly.  The host on their system accesses only control register and data registers.  It's not always the same, but random like writing data to config only, both config and gain, and so on.

4. What kind of data are written accidently?

(Ans)Their system uses only control and data registers, so they aren't sure if the data were always the same before adding monitoring the config/gain/zero registers, but it is the same now.  However the production version(w/o monitoring config/gain/zero registers) didn't always show the same behavior on IOUT pin, so they suppose it wouldn't had been the same.

5. Would you please provide the register dump before/after the issue?

(Ans)These are the dumped data examples after the issue occurs.  The expected values on their system are all 0s.

Config:21808.000

Gain:21808.000

Zero:1487.70

Best Regards,

Yoshikazu Kawasaki

Hi Yoshikazu-san,

Can the customer provide a schematic of their circuit?

Do they know what is causing the ALARM to occur? Can they read back the status register to see what fault has triggered?

I'm also a bit confused by their values for their registers after the communication issue occurs, are those the decimal forms?

Thanks,
Lucas

Hello Lucas-san,

I got the answers for your questions as shown below.  Would you please tell me how they should do to prevent the issue?

1. The following shows the peripherals of the DAC8750.  It shows AD5420 though.

2. The abnormal value they saw was only zero register.  The others are the same as before or after the issue.

Config:0x00

Gain:0x00

Zero:0x5530

Status:0x00

3. The values which looked like decimal were the internal values of their system and the abnormal value was only zero register.

Best Regards,

Yoshikazu Kawasaki

Hi Yoshikazu-san,

In the previously provided pictures, why is the SCLK stopping early? The customer's microcontroller should be providing a valid 24 bit write command.
The DAC doesn't have control of the SCLK and SDIN signals.

The customer could also use CRC frame error checking to ensure the integrity of the SPI data.

Thanks,
Lucas

Hello Lucas-san,

We had a holiday week, so my reply delayed.

They're aware of the behavior that the MCU stops clocking in the middle.  The issue here is that the competitor's DAC ignores the input in such cases, but DAC8750 seems to get the data and changes the registers affecting the Iout.  They see data for 8-clocks and stops for a while and resumes again for the rest of the 16-clocks.  Or 16 clocks following by 8 clocks.  Are you aware that it stops in the middle with LATCH=Hi and resumes after a while and it can change DAC8750 registers?  Does DAC8750 need to get data of 24-clocks in one time without changing LATCH=Hi in the middle?  How can they avoid the issue based on the fact that their system may stop sending data in the middle and resume after a while?

Best Regards,

Yoshikazu Kawasaki 

Hi Yoshikazu-san,

Section 8.5.1.4 of the Datasheet (page 31) mentions that not having the correct amount of SCLK cycles will result in incorrect data being programmed into the registers.

Section 8.5.1.1 mentions that the host must issue 24 bits before the rising edge of LATCH, meaning all 24 bits of data must be during a single low period of LATCH.


This device doesn't detect improper amounts of SCLK cycles.
Many of the newer DACs will not accept faulty commands with less than the required SCLK cycles.

Thanks,
Lucas