• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 649 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DRV10983-Q1: Unable to write to EEPROM, eeReadyStatus never = 1

user6140909
Prodigy 10 points
Part Number: DRV10983-Q1
Other Parts Discussed in Thread: TIDA-01496, USB2ANY
Hello,

I'm having some problems programming the EEPROM of a DRV10983-Q1 (the sleep version).

I'm working with a custom board and am able to send and receive messages from it over I2C.
The board is part of a project that I worked on about a year ago, but when I got stuck with the DRV10983-Q1 programming it was put on a shelf and forgotten.
Recently I started looking at the project again, but I am having the same problem; I can't program the EEPROM.

When reading the registers I seem to have managed to change some of them, but that must have been when I worked with the board a year ago.
The three first shadow registers [0x90:0x92] contain (during mass read) the configuration that I want to write, but the rest is somewhat random.

What I'm trying to do now is to just write the default configuration in all of the config registers, with no luck.

This is what is happening when following the EEPROM Access guide from the datasheet:

1. Power up with any voltage within operating voltage range (6.2 V to 28 V)
    - I'm powering it with 7.2v.
2. (DRV10983Q only) Exit from sleep condition
    - I'm applying a PWM signal @ 5KHz, 10% duty cycle.
    - The attached BLDC starts to spin. 
3. Wait 10 ms
4. Write register 0x60 to set MTR_DIS = 1; this disables the motor driver.
    - The BLDC now stops spinning.
5. Write register 0x31 with 0x0000 to clear the EEPROM access code
6. Write register 0x31 with 0xC0DE to enable access to EEPROM
    - Step 5 & 6 seems to go fine, the DRV acknowledges.
7. Read register 0x32 for eeReadyStatus = 1
    - This never happens.
    - I (almost) allways read 0x0000 from 0x32.
    - In a few rare cases I've gotten 0x8080 from 0x32.

I've tried to ignore the fact that eeReadyStatus never = 1, but that doesn't seem to work.
I've also tried adding a 50 ms delay between steps 6. & 7. as suggested in another thread on this forum.

Also, sometimes FaultReg (0x00) contains 0x0800, and once or twice I've seen 0x0900.
However, If I clear them, they don't occur again unless I cycle the power to the board. Should this concern me? 
The overcurrent flag (0x0800) I suspect is simply due to the motor configuration being wrong,
and the undervoltage fault condition (0x0100) is not consistently occurring.

I've also tried the alternate programming sequence described in the TIDA-01496 reference design.

I'm clueless about what to do next.
  • 0
    TI__Mastermind 24405 points

    Hi,

    Thanks for reaching out! The procedure that you have followed seems perfectly right to me but not sure why EEPROM not ready for read/write access. Let me check with my team and get back to you.

    Regards,

    Vishnu

  • 0
    TI__Mastermind 18900 points

    Hello User6140909,

    As Vishnu said, the sequence seems to be correct but I still have a few questions and assumptions:

    • Have you made your own PCB and using some external MCU or interface to send I2C commands to the DRV10983-Q1?
    • Do you have an oscilloscope for debug?
    • Do have the possibility to obtain a DRV10983-Q1EVM and USB2ANY for debug?

    UVLO:

    The undervoltage lockout leads on the 3.3V LDO is one path to follow. As you know, undervoltage lockout means that the (DRV10)983-Q1 device has determined that the 3.3V LDO is below an acceptable voltage. Note that the 983Q1 uses the 3.3V to power rails inside the device as well. This means, digital rails (e.g. rails that power the EEPROM block inside the device) could be at an insufficient voltage to function normally.

    If the UVLO is real, and "random", this usually means the 3.3V is noisy and bouncing around. Use an oscilloscope, and good probing techniques, to probe the voltage between the pin of the V3P3 and the ground of the decoupling capacitor that should be connected to the V3P3 pin. This can happen on custom PCB's with insufficient ground planes and ground return paths. This app note could help you review the layout http://www.ti.com/lit/an/slva959a/slva959a.pdf

    Another layout issue could be because of the power pad on the device not being sufficiently connected to the exposed GND pad that should be on the PCB. Unfortunately, there isn't a great way to check this. If you did assembly, I encourage you to use solder paste and good reflow techniques to ensure they're connected. If a PCB manufacturing company did assembly, then it should be a nonissue.

    Comments on EERPOM, shadow registers, and flow:

    I would just like to outline the usual flow and steps for those evaluating our device.

    1. Use I2C commands to program values into 0x90-0x96 (which are considered shadow registers that will be lost on power down, (i.e. volatile memory)
    2. Evaluate motor performance using settings
    3. Repeat steps 1 and 2 until performance is sufficient
    4. Go through EEPROM programming process to copy shadow register contents into the EEPROM block, inside the device, to save settings after powering down (i.e. nonvolatile memory)

    If you are hitting current limit, I would say you're still in steps 1-3 as the settings. I'm sure you know of the tuning guide: http://www.ti.com/lit/ug/slou477/slou477.pdf

    If you aren't getting NACK's very often and you can read back the values you wrote, then I'm going to assume your I2C ecosystem is good. With that being said, if you followed the recommendation to use I2C pullups connected to V3P3, then you might have a risk to have some corrupt waveforms if the 3.3V isn't stable.

    Final Debug tips:

    It is always good to have a known good set up for debug.

    The DRV10983-Q1EVM (with a replaced sleep mode version device) would represent a known good layout. Another known good PCB of your (assumed) design would represent  the same layout but different components (and different 983Q1). A USB2ANY would represent a known good I2C interface. Unsoldering the 983Q1 and putting it on a different PCB would help you track if the problem follows the device (which would eliminate the layout or components as the issue).

    This concept is known as an AB swap, it would help you narrow down where the problem could be.

    Good luck and let us know if you have any questions.

    Best,

    -Cole