Motor drivers forum - Recent Threads

DRV2605L: DRV2605L creates weak haptic responses & randomly dies

Shilpa Rao — Fri, 21 Aug 2026 23:15:47 GMT

Part Number: DRV2605L

Hello!

Our team is having two separate issues with this chip.

Weak haptics issue

We use a DRV2605L in ROM mode on our PCB. It vibrates when the user "squeezes" our device, and we detect this squeeze using a hall effect sensor. We mount the LRA motor to the chassis of our device using glue. The resonant frequency of our LRA is 180 hz. The DRV2605L is driven by a rail that swings from 2.5v to 5v. VSYS is either at battery voltage (3v to 4.2v) or stable USB-C +5v. It switches to USB-C 5V when a cable is plugged in.

We have empirically noticed that some assembled units fail the DRV's auto-calibration. In the units that fail auto-cal, the LRA motors usually also feel weak. Only a few units experience the “weak haptic” behavior. The rest have been fine while undergoing daily use for several months by our team members.

The other day, I noticed a relationship between VSYS and auto-cal success. I found that 2-3 units failing auto-cal had a battery voltage of around 3.83 volts. When VSYS was brought up to USB 5v, it passed auto-cal and the expected LRA vibration strength returned.

Our team wrote a custom driver to control this chip. I found that the rated voltage was set to 2.5 Vrms and the overdrive clamp to 2.5v, so I reduced the rated voltage to 1.8vrms to resolve the difference. I believe that the 1.8vrms edit helped, if only because it resolved a conflict between the requested voltage and the clamped voltage in the firmware. Empirically, this intermittently helps several NG units pass auto-calibration. Despite this, we are still seeing intermittent auto-calibration failures.

I have a few theories.

I wonder if, for some reason, the DRV2605L is losing frequency lock. I know the DRV2605 chip has an FB_STS register that our -L variant does not. From the -05 datasheet, "[FB_STS] indicates when the ERM back-EMF has been zero for more than ~10 ms in ERM mode, and indicates when the LRA frequency tracking has lost frequency lock in LRA mode". Is there a variant of this feedback we can access on our -05 chip?
Perhaps the bemf crossing is being detected at the wrong time? Maybe the flow goes like this: voltage sag at threshold batt voltage -> detection of bemf crossing at the wrong point in time -> incorrect period -> incorrect frequency -> auto-cal fails at frequencies the LRA can't handle
Perhaps there is some mechanical variation between motors that puts calibration/haptic performance right on the edge of what the DRV chip can handle? All motors have the same resistance though.

DRV2605L sudden death issue

This week we’re manufacturing new iterations of these units, still with the DRV2605L. We’ve included a motor calibration test on the factory line to try and catch the units with weak haptic responses. Due to this new test, we discovered another failure mode that has been confusing us. To my knowledge, this has not happened to any of our boards before. In four separate boards, the DRV2605 chip stopped acknowledging writes over i2c in our firmware despite the power rail being up (3.9v in all 4 instances) and the enable line high (1.8v). Despite several hardware resets, the chip has not come back on. There is simply no haptic response at all. This happened on brand new boards.

In 3 out of the 4 boards, the motors were never driven successfully. Our operators failed the boards at the very first station where motor behavior is ever tested due to a lack of haptic response. In the 4th instance, however, the board was flagged for having the “weak haptics” issue described above. After auto-calibrating it in firmware, the motor failed approximately 5 attempts at auto-cal (confirmed by the chip over i2c), and then the DRV chip stopped responding altogether. I have not been able to bring it back up.

I believe we may be dealing with two separate issues related to the chip now. I know the DRV2605L has an “unknown state” that can be triggered by a specific power sequencing scenario, and we have in fact seen a possible consequence of that (specifically, we’ve noticed two drivers outputting a DC voltage between the haptics +/- differential terminals and heating the motor perceptibly. Desoldering & soldering the battery solved this). To preemptively fix future heating issues, we assumed the chip to be in an unknown state and implemented a delayed enable in firmware to solve this. We have not seen overheating motors on our factory line since, but we have seen (seemingly random) DRV deaths.

To any TI experts on the DRV2605L - have you ever encountered weak haptic outputs from this chip? We're more concerned about that than the dead chips. It is our priority to figure out the source of variation resulting in a weak haptic response. This directly affects the user's experience with our product.

Additionally, if there is a quick answer to the sudden chip death, we'd appreciate leads there as well.

Thank you!

RE: DRV2605L: DRV2605L creates weak haptic responses & randomly dies

Shilpa Rao — Fri, 21 Aug 2026 23:21:47 GMT

Just to follow up with some logic analyzer captures -

I suspect the chip because the output stage delivers an visibly unhealthy vibration pattern to the connected LRA in the case of a weak haptic response.

Here's one example of an auto-calibration attempt where the motor failed auto-cal four times before it passed. The white line is Vsys, which has visible & repeatable sag during a haptic event. Vsys was 3.83 volts during these tests - right on the boundary of where we're observing this failure.

^ Zooming into a failed auto-cal attempt, you can see that the DRV2605's output stage attempts to deliver an asymmetric output signal to the motor.

I measured the period of an auto-calibration failure waveform. 1/(2.206e-3) = 453.309 hz, even though in firmware we tell the DRV2605 to drive at 180 hz.

Sometimes, despite the battery having a voltage of 3.83 or lower, auto-calibration passes. I was able to capture a healthy waveform on my logic analyzer. For a successful auto-cal attempt, the waveform is symmetric.

The period of the DRV2605L during a successful auto-cal attempt is 1/(5.76e-3) = 173.611 hz, which roughly matches the frequency we command in firmware.

The relationship between power & motor performance has stumped me. I don't understand why raising the voltage rail from 3.82 to 5 volts could make or break the performance of the DRV2605L output stage. Since we are close to production with our hardware, we unfortunately cannot edit the boards to use PWM mode. Can you help us figure out why we sometimes observe NG behavior in ROM mode?

DRV8833: DRV8833: nFAULT asserted for entire nSLEEP-high duration

Ryan Drake — Fri, 21 Aug 2026 22:18:37 GMT

Part Number: DRV8833

Hi,

I'm seeing `nFAULT` behave in a way I can't reconcile with the datasheet's documented fault conditions, on a PCB using two DRV8833 (PWP/TSSOP-16) driving three small DC motors. I'd appreciate a sanity check on whether this is expected/known behavior, or a sign of something wrong in my design.

My application consists of two DRV8833 chips, one driving two DC motors (A and B bridges), one driving a single motor (A bridge only). 0.2 ohm current sense resistors are installed for each bridge's sense pins.

nFAULT is wired in common between both chips, with a 10k ohm pull-up resistor to 3.3V.

Both chips share one VM rail, 6V, fed from a 1000 uF bulk cap plus a local 10 uF ceramic at each chip's VM pin, per the datasheet's decoupling guidance.

MCU is an ESP32-S3 toggling nSLEEP to 3.3V in firmware, which is wired in common to both chips' nSLEEP pins.

The symptom: When I drive nSLEEP high from the MCU, each chip's nFAULT goes low instantly, within roughly 100-150 microseconds. Without commanding any motor input. nFAULT stays low for as long as nSLEEP remains high, and then returns high as soon as nSLEEP is driven low again. Commands to run each bridge's motor work fine--motors run as expected, even while nFAULT remains driven low.

Both chips behave this way independently (checked by wiring their nFAULT lines separately).

The datasheet says nFAULT will only be driven low upon overcurrent protection (not happening because there is no motor duty commanded), thermal shutdown (my chips not getting hot), and undervoltage lockout (motors would not run if this were the condition).

Is there a mechanism by which `nFAULT` would assert for the entire duration the device is awake, on every wake, with zero and non-zero commanded current, without actually disabling the driven bridge's output? This doesn't seem consistent with the table in section 7.3.5 of the datasheet.

RE: LMGXX-GAN-LLC-CALC: LMG3100R017VBER simulation models

EricLee — Fri, 21 Aug 2026 21:03:37 GMT

Hello Albert

Sent the model to Guyath

-EL

LMGXX-GAN-LLC-CALC: LMG3100R017VBER simulation models

Albert Barroso — Wed, 29 Jul 2026 21:13:02 GMT

Part Number: LMGXX-GAN-LLC-CALC

1) Can I get a simulation model for the GaN MOSFET power stage LMG3100R017VBER PSIM or a datasheet that I can parameterize in PSIM to simulate it ?

2) What is the tool you reccomend using to simulate the LMG3100R017VBER in a 3-phase SVPWM FOC inverter ?

3) Our 3-phase inverter needs to deliver 2100W of power to a brushless motor, and 6 LMG3100R017VBER are going to be liquid cooled with a fast 65C moving fluid. Do you think our inverter is in its SOA or we are abusing it ?

4) Is TI developing a LMG3100R008VBER with a 0.8 milliohm Rds_on ?

onsemi released a 100V 0.8 milliohm Rds_on GaN MOSFET but needs an external gate driver.

NTLEF1D0N10GN1 - Enhancement Mode Gallium Nitride (GaN) HEMT 100 V, 0.8 mOhm, TBD A, PDSO‐N8

DRV8718-Q1: Question about schematic of DRV8718-Q1

Chase Jeong — Fri, 21 Aug 2026 09:45:49 GMT

Part Number: DRV8718-Q1

Dear TI experts,

Last December I requested schematic review of DRV8718-Q1 and I got a result from TI expert.

https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1590276/drv8718-q1-please-review-the-schematic-of-drv8718sqrvjrq1/6127525

Now my customer consider revision of PCB, so recently they review the result once again.

One of the expert's suggestion is, adding >10uF+0.1uF caps close to PVDD pin.

But my customer think that is it not necessary because Customer already added 560uF+560uF+100nF in same node(VMTR_FI_12V).

Could you check the reason why my customer add 10uF+0.1uF caps although there are enough caps in same node?

Best regards,

Chase

RE: DRV8718-Q1: Question about schematic of DRV8718-Q1

Shinya Morita — Fri, 21 Aug 2026 19:49:48 GMT

Hi Chase,

Generally, IC requires decoupling cap close to IC. This is very common and documentation can be found in google/web etc.

Please refer 9.4.1 Bulk cap sizing.in Datasheet.

Furthermore, as general workaround for EMC, better to have 0.1uF and 10uF close to PVDD pin. They should be ceramic cap. Better to put 0.1uF closer to pin.

regards

Shinya

DRV8245-Q1: SPI communication is not working

Khamruddin Shaik — Fri, 14 Aug 2026 19:12:27 GMT

Part Number: DRV8245-Q1

Hello ,

I am using DRV8245 SPI variant , after power up , I am making sleep as 1 and waiting for 62.5ms and I am trying to read the device id . I am receiving F0C0 as response . What might be the issue here ?

RE: DRV8245-Q1: SPI communication is not working

Joshua Horlander Cruz — Fri, 21 Aug 2026 18:48:05 GMT

Couple of questions:

What is the VM voltage?
Is the nFAULT pin pulled to GND or is it high?
Is this on a custom PCB or on the DRV8245S-Q1LEM?
1. If this is on a custom PCB is there any passive components on the SPI lines?
Can a capture of the SPI signals for the DEVICE_ID read be provided?

0xC0 is not a default value for any register or the DEVICE_ID so I am checking if there is any issue with the SPI communication. I am also looking for the VMOV fault that is reported since this would help confirm that the SDO information is being read correctly.

Regards,

Joshua

DRV8304: DRV8304: Is there an evaluation board variant of the DRV8304 that supports SPI communication ?

Arivalagan P — Wed, 19 Aug 2026 06:27:50 GMT

Part Number: DRV8304

We are planning to purchase a DRV8304 evaluation board. However, I noticed that the TI website currently lists the DRV8304H evaluation board, which supports hardware control.

Could you please confirm whether an SPI-supported version of the DRV8304 evaluation board is available?

RE: DRV8304: DRV8304: Is there an evaluation board variant of the DRV8304 that supports SPI communication ?

Joseph Ferri — Fri, 21 Aug 2026 18:46:09 GMT

Hello,

This is probably connected to the PIN 26 of the device, which on H variant is MODE pin which connects to GND for 6x PWM mode, whereas on the SPI variant, this is the SDO pin which requires an external pull up.

Thanks,

Joseph

RE: DRV8263S-Q1EVM: DRV8263-Q1 EVM power supplier issue

Joshua Horlander Cruz — Fri, 21 Aug 2026 18:39:15 GMT

I am sorry there is a mistake on the EVM that we are fixing please depopulate the D4 diode and the board should have no issue supporting 48V input. This diode is a 32V diode form VBATT to GND that was intended to not be populated but it has been populated on some of our EVMs.

Regards,

Joshua

DRV8263S-Q1EVM: DRV8263-Q1 EVM power supplier issue

zhudong wang — Mon, 17 Aug 2026 06:21:31 GMT

Part Number: DRV8263S-Q1EVM

After applying 48V to the DRV8263-Q1 evaluation board, I smelled a bit of burning, so I changed the voltage to 12V, but I only measured 0.02V on the board. I checked the fuse, it's fine(It shows continuity when tested with a multimeter). Why can't this board handle 48V, and what should I do next to get it running again?

RE: TPS62420: Regarding the resistance value of DEF_1 for the TPS62420

Febin — Fri, 21 Aug 2026 16:16:58 GMT

Hi Tsu,

Section 9.1.1 in the datasheet has TI recommendations for choosing feedback resistors.

There are no recommendations for lower limits. However there is always a trade-off. Please have a look at this App note.

Thanks,

Febin

TPS62420: Regarding the resistance value of DEF_1 for the TPS62420

tomoyuki tsujimura — Thu, 20 Aug 2026 12:39:35 GMT

Part Number: TPS62420

Hi TI Support Team,

Thank you for your continued assistance.
I have a question about the feedback resistor values for the TPS62420.
My current design follows the typical application schematic, with the following settings:

VIN = 5 V
VOUT1 = 3.32 V
R11 = 340 k
R12 = 75 k
L1 = 3.3 uH
COUT = 33 uF
The circuit is operating without issues. To improve noise immunity, I am considering changing the feedback resistors to:
R11 = 82 k,R12 = 18 k
Could you please advise on the following

1)Are there any concerns with using R11 = 82 k and R12 = 18 k
Low power consumption is not a priority in this design.

2)Are there recommended lower limits for R11/R12 or R21/R22

Thank you in advance for your advice.
Best regards,
T. Tsu

DRV81080-Q1: DRV81080-Q1: Is an External Pull-Up Circuit Required for MCU Interface Signals?

YUN LIN — Fri, 21 Aug 2026 09:05:31 GMT

Part Number: DRV81080-Q1

Hi TI team,
In the schematic, the controller is connected to the DRV81080-Q1 through series resistors only. Is any external pull-up supply circuit required for the interface signals (nSLEEP, IN0, IN1, nSCS, SCLK, SDI, and SDO), or are the series resistors alone sufficient?

RE: DRV81080-Q1: DRV81080-Q1: Is an External Pull-Up Circuit Required for MCU Interface Signals?

Mojtaba Afshar — Fri, 21 Aug 2026 16:15:05 GMT

Hi Yun

Thank you for your question.

[quote userid="436983" url="~/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1675394/drv81080-q1-drv81080-q1-is-an-external-pull-up-circuit-required-for-mcu-interface-signals"]In the schematic, the controller is connected to the DRV81080-Q1 through series resistors only. Is any external pull-up supply circuit required for the interface signals (nSLEEP, IN0, IN1, nSCS, SCLK, SDI, and SDO), or are the series resistors alone sufficien[/quote]

No there is no need for external pull up on anu interface pin and adding series protection resistors would be enough. For reference, please check the DRV81080-Q1 EVM schematic.

DRV81080-Q1EVM Evaluation board | TI.com

Regards

Mojtaba

DRV8874: Why did the VM and VCP pins of DRV8874 get damaged during the power-on transient?

Guijiao Zeng — Fri, 31 Jul 2026 11:32:18 GMT

Part Number: DRV8874

Hi,

I have already started mass production. Now we have found that in three cases, the DRV8874 starts to smoke and get damaged as soon as it is powered on.

The VM and VCP pins of the chip have been short-circuited to ground, while the other pins are normal, and the peripheral components of the chip are also normal.

See PIC1

Because three such failures occurred randomly, and the chips were already damaged during the startup process, I tested the transient waveforms during startup.

See PIC2

Furthermore, I would like to provide the following additional information.

See PIC3~5

24V_IN is provided by the medical power adapter.

When testing the current, remove fuse F3, solder the wire, and use the clamp-type current probe for testing.

My question:

Does this kind of power-on transient fault phenomenon, which only causes damage to the VM and VCP pins, result from inappropriate nSleep timing, or is it caused by some other reason?

That's all. Thanks for your reply.

RE: DRV8874: Why did the VM and VCP pins of DRV8874 get damaged during the power-on transient?

Yuzhou Yao — Fri, 21 Aug 2026 15:22:49 GMT

Hi Guijiao,

Thank you for your reply. Could you please let us know if there is any specific reason that the waveforms in pic7 and pic 8 seem to be different if both of them are the waveforms measured between CPL and GND during start up? like I didn't see the negative voltage spike in pic 8. And point 2 sounds good. Please let us know if you still have any start up failure after you changed C68 to 22 nF. For the charge pump design, we have run the simulations and experimental tests for all of the recommended values, so there shouldn't be any start up failure after you used recommended charge pump flying capacitor value. Thank you!

Best,

Yuzhou

RE: DRV8838: Request for Technical Support on DRV8838DSGR Failure

Murugavel4637 — Fri, 21 Aug 2026 13:43:10 GMT

Hi Liang,

Thanks for reaching out to us via this forum.

[quote userid="631241" url="~/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1675359/drv8838-request-for-technical-support-on-drv8838dsgr-failure"]

Failure Description

No sound or significantly reduced sound was generated from the buzzer at the PCBA level.
Log file data indicates that both devices successfully passed the Manufacturing Buzzer Self-Test, suggesting that the buzzer circuitry was functioning correctly during production.

[/quote]

As per this description it appears to be a device failure - the log file indicated these devices passed production self-test. I assume these failures were from the field after some period of time in use.

[quote userid="631241" url="~/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1675359/drv8838-request-for-technical-support-on-drv8838dsgr-failure"]

Based on our preliminary analysis, the issue appears to be associated with the buzzer driver IC BDBIANA1061715-R (TI P/N: DRV8838DSGR).

To further verify the failure, we performed a component swap test:

The suspected failed IC was removed from the defective PCBA and installed onto a known good PCBA.
The same failure symptom was reproduced.
This result suggests that the issue is associated with the IC itself rather than the surrounding circuitry.

[/quote]

This confirms the issue followed the suspected IC.

[quote userid="631241" url="~/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1675359/drv8838-request-for-technical-support-on-drv8838dsgr-failure"]We would appreciate your support in understanding the potential failure mechanisms behind the observed electrical behavior.JS2632-F-0246 Failure Analysis Report for BD.pdf [/quote]

All the below IC markings verified to products from different lots of the same manufacturing flow and technology. They should be electrically identical. Each IC goes through automated test ATE with a complete suite of tests to ensure the IC is in compliance with the product datasheet. These ICs leave our factory only if they PASS with the set limits in the final test.

All these point to a latent failure of the IC due to external reasons. It could be application's internal electrical related (absolute max. violation) or physical use case (such as ESD) that may have damaged these ICs.

See below absolute maximum specifications for this IC from its datasheet. If any of these were exceeded the IC would fail eventually.

You mentioned the application was a buzzer. Was it a piezo buzzer or inductive load. The DRV8838 is designed for driving inductive loads within ranges of brushed DC motors or solenoids. Driving capacitive loads or LC loads could cause voltage spikes on OUT1, 2 pin and/or reflect back to VM and if the spike exceeds the operating specification it could damage the IC.

Can we review OUT1,2 and VM waveforms under normal operating conditions? What are the operating voltage values in the application and a schematic for review would be helpful for further debug. Thank you.

Regards, Murugavel

DRV8838: Request for Technical Support on DRV8838DSGR Failure

liang gavin — Fri, 21 Aug 2026 08:09:44 GMT

Part Number: DRV8838

Dear Team,

Our customer has reported that two PCBAs exhibited a no-sound/low-sound issue from the buzzer during operation.

Failure Description

No sound or significantly reduced sound was generated from the buzzer at the PCBA level.
Log file data indicates that both devices successfully passed the Manufacturing Buzzer Self-Test, suggesting that the buzzer circuitry was functioning correctly during production.

Initial Investigation

Based on our preliminary analysis, the issue appears to be associated with the buzzer driver IC BDBIANA1061715-R (TI P/N: DRV8838DSGR).

To further verify the failure, we performed a component swap test:

The suspected failed IC was removed from the defective PCBA and installed onto a known good PCBA.
The same failure symptom was reproduced.
This result suggests that the issue is associated with the IC itself rather than the surrounding circuitry.

In addition, we conducted component-level I-V curve characterization. The test results showed:

"I-V characterization revealed increased leakage and early conduction on multiple pin pairs of the DUT parts (U4) when compared with reference good parts, while no obvious abnormalities were observed on several other pin combinations."

Technical Inquiry

We would appreciate your support in understanding the potential failure mechanisms behind the observed electrical behavior.JS2632-F-0246 Failure Analysis Report for BD.pdf

From a theoretical semiconductor perspective, could you please help explain the possible causes of:

Increased leakage current between pins
Early conduction at lower-than-expected voltages

LM3478: Technical Consultation

archer Ye — Wed, 12 Aug 2026 02:11:31 GMT

Part Number: LM3478

Hi,

We encountered an intermittent issue when using LM3478QMMX/NOPB. Details as follows:
At 12V supply, the chip operates normally. At 16V power-on, the PWM driver shuts down, then PWM becomes abnormal.
Please advise:
1. What could be the possible root causes?
2. What additional information can we provide to assist your analysis?

Thank you and best regards.

Sandy Yang

RE: LM3478: Technical Consultation

archer Ye — Fri, 21 Aug 2026 13:12:42 GMT

Dear Niklas,

As a supplement to our previous discussion, please find attached our ABA test report for your review. This report documents the comparative testing results we mentioned earlier, including the failure reproduction tests and the ABA verification data.

Should you have any questions or need additional data, please feel free to let us know.

e2e.ti.com/.../LM3478QMM-FA-Report.docx

Best regards,

Sandy Yang

RE: LM3478: Technical Consultation

archer Ye — Fri, 21 Aug 2026 12:51:31 GMT

Dear Niklas,

Thank you for your prompt response and the suggestions regarding potential design-related root causes.

Regarding the Application Information You Requested:

The output target voltage in our application is 24V. Regarding the topology used, input voltage range, output power during startup and during operation, and the application schematic, we are still in the process of gathering this information from our design team.

Additionally, as the schematic involves internal confidential information, we would like to confirm whether you would be able to provide a direct email contact for secure transmission. Once we obtain these details, we will forward them to you accordingly.

Our ABA Testing Results:

In parallel, we would like to share the ABA (Apply-Best-Apply) comparative testing results we have conducted, and we would appreciate your assessment on whether any conclusions can be drawn from this data.

We conducted the following tests.

- First, a PCBA that failed FCT at end-of-line was tested with the original LM3478QMMX/NOPB installed, and it failed. After replacing the LM3478QMMX/NOPB with a new unit, the same PCBA passed FCT testing.

- We then transferred the failed LM3478QMMX/NOPB to a known-good PCBA board. Upon powering up at 16V input, the unit showed current fluctuation, no voltage output, and abnormal power drive waveforms.

- We also tested a normal PCBA board at 16V input. The power supply voltages were measured at lower bridge 23.26V, resolver 23.88V, and upper bridge 23.76V/23.73V/23.78V, with normal power drive waveforms observed.

Based on these ABA comparison tests, we have preliminarily isolated the issue to the LM3478QMMX/NOPB IC.

Additional Information from Our Records:

We noted that there were four failure cases in July at the FCT test station, and two additional units reported Fault Code 74 (24V voltage abnormal) in early August at the aging test station. The failed power ICs in these cases were from the same batch with Date Code 2614.

The failed unit information is as follows: Part Number LM3478QMMX/NOPB, Quantity 1 pcs per board, Manufacturer TI, Marking 63HE.
Please let us know if the above ABA test data is sufficient for any preliminary assessment, or if additional information would be helpful.

Best regards,

Sandy Yang

MCF8329HS-Q1: Question about default offset

Chase Jeong — Mon, 10 Aug 2026 09:17:32 GMT

Part Number: MCF8329HS-Q1

Dear TI experts,

Could you check that the offsets of GATE_DRIVER_FAULT_STATUS is 0h and CONTROLLER_FAULT_STATUS is 2h?

I am asking it because if my customer read this offset, it is read as fixed value.

So I need to check it is not 0h -> E0h and not 2h -> E2h.

Please check this issue. Thanks.

Best regards,

Chase