DRV8353: DRV8353 Phase B Offset Issue

Joshua,

Thank you for your reply.

If it is a Vref stability issue, why does it only happen on Phase B? Wouldn't we also see it randomly on the other phases as well?

Hi John,

I'll look into the reason behind the VREF recommendation.

In the meantime could you provide the following information / answer the following questions:

1. Can you provide a capture of the offset error you are experiencing?

2. Does the offset persist after a manual calibration (assuming you are using a SPI variant of the DRV8353)?

3. Does this issue happen across multiple devices/PCBs? Have you performed an ABA swap with a good device/PCB to see if it's more a device or application issue? Does this happen at certain temperature or supply voltage?

Thank you,

Joshua

Joshua,

Regarding #1:

I will follow up with this information.

Regarding #2:

We do not have a routine for using the manual calibration. However, we have manually triggered the auto-cal during run time and observed the same offset on Phase B as was observed after power up or reset.

Regarding #3:

Yes, and testing has been performed at nominal conditions (room temperature and nominal supply voltage).

Joshua,

For #1 - see below for phase B output. Each pulse is an enable cycle on the DRV (causing a new auto-cal event). The image captures an instance of "abnormal" offset where the output is off by 25mV.

For clarity on #3: it's a 24V system. DRV Vm = 14V and Vref = 3.2V. Vref input includes filtering.

Hi John,

1. Does this offset issue occur on multiple boards ?

2. Does the error still appear if you perform an ABA swap with a chip experiencing this issue?

3. Could you provide a capture of VREF at startup, I would like to see if your VREF is the same as was seen in the other thread.

Thanks,

Joshua

Josh,

We've been able to resume testing on this. Please note the issue is not yet resolved. Will follow up with answers to your questions later today or tomorrow

Any feedback from your side regarding Vref? I had asked previously why instability in the Vref node could have affect on one SOx and not the others.

Hi John,

The idea was that if the devices auto-calibration mode calibrates one CSA after another and not all of the CSAs at once, then an unstable VREF voltage could allow for some phases to be affected and not others.

Regards,

Joshua

Joshua,

I would think that an unstable Vref could randomly affect all 3 phases regardless of whether the auto-cal routine is done sequentially or not. That's not what we've observed, where phase B appears to be the primary victim.

But based on your statement, which implies that the auto-cal routine is done sequentially, I am curious -- does the routine always do the phases in the same order?

Test results are still pending, I should have additional sample results tomorrow. Thank you again for the continued support and discussion.

Hi John,

John Puckett said:

But based on your statement, which implies that the auto-cal routine is done sequentially, I am curious -- does the routine always do the phases in the same order?

Sorry for the confusion, it is currently an assumption that the auto-cal routine is done sequentially. I reached out to my team and this was the most likely reason that the stable VREF recommendation was made. 

Regards,

Joshua

Joshua,

Let me rephrase my question. During power up, or when we come out sleep mode, the auto-cal routine is performed. Does the auto-cal routine run on all 3 of the phases simultaneously or sequentially? And if it is sequentially, is it always in the same order?

John,

The auto-cal routine on the DRV835X devices calibrates the devices in parallel.

Regards,

Joshua 

Joshua,

During normal operation (powered on, enabled), if the Auto-Cal is enabled (CAL_MODE = 1) - does setting any CSA_CAL_n bit trigger the auto-cal for 3 phases? Or would it require all 3 CSA_CAL_n bits to be set at the same time?

John,

If AUTO_CAL is enabled and the device is running, setting any CSA_CAL_X bit high will re-run the auto_cal routine on the corresponding phase. If you would want to re-run the auto_cal routine on all phases at the same time during normal operation then all three of the CSA_CAL_X bits would need to be set high at the same time.

Regards,

Joshua

Joshua,

We've tested 3 different instances where the auto-cal is run.

1. Drive module power up

2. DRV Enable OFF to ON (DRV coming out of sleep mode)

3. Manual initiation of Auto-CAL via CSA_CAL_X bit(s)

We've observed the offset issue in all 3 instances above, on multiple samples, different component lots and product design options. I'm going to follow up to this post with an attachment that includes some of this data.

As we expanded our testing we also observed that the other phases would show the offset issue (not just SOB). We did always have at least 1 phase that did not have the offset issue.

Question: does the auto-cal routine operate any differently during Enable OFF to ON (coming out of sleep mode)?

Updated: see image below - the step change in phase B occurs after the Enable OFF to ON occurs.

Yellow: SOA (stays the same)

Red: SOB (shifts in level)

Blue: SOC (stays the same)

Green: Vref (3.15V, where we're using Vref/2)

Joshua,

See the images below. As before, below are the labels for each waveform:

Yellow: SOA (stays the same)

Red: SOB (shifts in level)

Blue: SOC (stays the same)

Green: Vref (3.15V, where we're using Vref/2)

The transition here is when Enable goes from OFF to ON. (Vref is already up, as you can see)

The top two images are zoomed at 50us divisions. Here we see (what must be) the auto-cal routine trimming the offset. You'll see that in this case, from one instance to another (same sample, done a few minutes apart), the offset for phase B is lower than the other.

The lower two images are for the same sample, at 20ms divisions.

Joshua,

More data - as before, labels are the same (same sample).

Yellow: SOA (stays the same)

Red: SOB (shifts in level)

Blue: SOC (stays the same)

Green: Vref (3.15V, where we're using Vref/2)

Here we're manually triggering the auto-cal (for all 3 phases) while DRV is enabled. The same step in offset is observed for phase B.

Joshua, 

More data, last for today. As before, labels are the same (same sample).

Yellow: SOA (stays the same)

Red: SOB (shifts in level)

Blue: SOC (stays the same)

Green: Vref (3.15V, where we're using Vref/2)

This is when the manual auto-cal is turned OFF. The datasheet indicates that the gain changes to max setting when auto-cal is run, and that is must be why we see a change here, although it doesn't appear to be consistent for each phase.

Is it possible the auto-cal routine doesn't adjust the gain correctly every time?

Hi John,

I will need some time to look over the information you provided and the questions you asked. I will get back to you by next Thursday at the latest.

Regards,

Joshua

Hi John,

Could you provide a capture of the SPx, SNx, SOx, and VREF pins of a CSA with an incorrect offset, before and after the offset error occurs? Also, can you provide the gain setting you are using? We would like to check if the CSA is following the equation Vin = ((Vref / 2) - Vsox) / Gain.

John Puckett said:

Question: does the auto-cal routine operate any differently during Enable OFF to ON (coming out of sleep mode)?

The auto-cal routine will operate the same as when the device is powered on as when the device is brought out of sleep mode.

Regards,

Joshua

Joshua,

See below. These are Enable cycles, so auto-cal happens on each one. We are using the default Gain = 20V/V.

Yellow: SPB (CH1)

Red: SNB (CH2)

Blue: SOB (CH3)

Green: Vref (where we're using Vref/2)

1st Image: Cycle before offset change - top plot shows collected data, with bottom plot zoomed in on the area indicated by red arrow.

2nd Image: Cycle showing offset change - top plot shows collected data, with bottom plot zoomed in on the area indicated by red arrow.

3rd Image: Cycle after offset change (appears to return to higher value) - top plot shows collected data, with bottom plot zoomed in on the area indicated by red arrow. Note - for each plot, the "measured" mean values come from the range indicated by the orange arrows.

Joshua,

These are similar scope captures, but without zooms. The Measured values are now from ranges inside each enable cycle (orange arrows).

Yellow: SPB (CH1)

Red: SNB (CH2)

Blue: SOB (CH3)

Green: Vref (where we're using Vref/2)

1st Image: Cycle before offset change

2nd Image: Cycle showing offset change

3rd Image: Cycle after offset change (appears to return to higher value)

Joshua,

See below. These are Manual Auto-cal cycles. Here we see the SOB output alternates settling in at the higher value and the lower value. Blue arrows indicate where atuo-cal is enabled (Digital1 is low). Orange arrows indicate when auto-cal is not enabled (Digital1 is high).

Yellow: SPB (CH1)

Red: SNB (CH2)

Blue: SOB (CH3)

Green: Vref (where we're using Vref/2)

1st Image: measured mean values for SOB at higher value (range at 1st orange arrow)

2nd Image: measured mean values for SOB at lower value (range at 2nd orange arrow)

Hi John,

After looking at the captures you provided the input offset error that we calculated was within the devices specification of +/- 3mV. It is possible for the input offset error to be different per-phase and for the error to change every time the device is powered up.

That said, we would like to determine if the noise on the input signals is causing any issues. Could you short the input signals as close to pins as possible and capture SPx, SOx and Vref?

Could you also provide your schematic and shunt resistor value?

Regards,

Joshua

Joshua,

Any feedback regarding the operation of the auto-cal routine?

We're obviously seeing behavior that isn't expected in the shifting of the SOx level.

We also see that the outcome of the auto-cal routine is different when coming out of sleep mode vs. manually triggering it.

How does the input offset error relate to these things? How would noise on the input signal cause these things?

What about the Gain - could this not be getting set correctly internally before/during/after auto-cal? Has this been considered?

Hi John,

John Puckett said:

Any feedback regarding the operation of the auto-cal routine?

Based on the captures and information we have seen we do not believe that the auto-cal routine is the reason that there is a difference in the offset per phase.

John Puckett said:

We're obviously seeing behavior that isn't expected in the shifting of the SOx level.

We believe that the shifting in the SOx level is expected, The input offset error will cause the output to shift by +/- 3mV. From the mean measurements in the captures that were provided we determined that the error of the shift was within datasheet specifications.

John Puckett said:

How would noise on the input signal cause these things?

We wanted to make sure that there was nothing on the inputs that could have been amplified and contributing to the offset.

John Puckett said:

How does the input offset error relate to these things?

Input offset error results in a corresponding error on the CSAs outputs and the calibration does not perfectly remove the offset error resulting in the +/-3mV offset error specification in the datasheet that is being seen.

John Puckett said:

What about the Gain - could this not be getting set correctly internally before/during/after auto-cal? Has this been considered?

The device will set the gain of the CSA to the max, considering that the input offset is within datasheet specifications, this does not seem to be an issue.

Regards,

Joshua

Joshua,

To summarize: A shift in the output like what we've shown (10x of mV) is expected and the auto-cal routine can't completely remove it.

So, is the output offset error equal to the gain multiplied by the input offset error? I ask this because the datasheet doesn't spec the output offset error (just the input offset error of +/-3mV). If this is the case - then the "being within specifications" argument makes more sense. Because at 20V/V, that would imply an output offset range error of +/-60mV.  Figure 43 (below) seems to allude to this VSO offset being related to the input offset, but no additional detail is provided.

Hi John,

John Puckett said:

So, is the output offset error equal to the gain multiplied by the input offset error?

Correct, the input offset error will be amplified by the gain leading to a greater offset seen at the output.

Regards,

Joshua

Joshua,

A big thanks to you and your team for the support on this issue. We have established that the part operates within specification, and that the offset shift is expected.

However, I do not feel that we have resolved the issue of why the shifting offset behaves the way that it does and how the auto-cal routine factors into that. Nor do we have a clear explanation as to why the outcome of the auto-cal routine is different between enable cycling vs. manual cycling.

Our team is trying to come up with a way to design around this issue for our current development. We are looking at trying to use the manual auto-cal to help us (as it tends to behave more consistently). That being said, our future designs may need to move away from using the 8353 and towards the 8350 or equivalent.