• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 328 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 access EEPROM registers, eeReadyStatus never = 1

Jay Smith
Prodigy 10 points
Part Number: DRV10983-Q1
Other Parts Discussed in Thread: TIDA-01373

A little background on what has happened. I have been successfully using this driver to run a BLDC motor and control it's speed.

I was making adjustments to the configuration registers and saving to EEPROM and seeing that the new configuration parameters were successfully saved and being used.

Two days ago, the controller stopped responding to I2C commands. Error returned was a bus collision error. I put a scope on the bus and noticed the data and clock lines were not being pulled high.

My design uses the 3.3V output of the DRV10983-Q1 with resistors for pull-up and there was no 3.3V coming from the chip when power was supplied to the controller. Motor was not running.

My initial thought was that the controller has burned out for some reason, but I don't give up that easily. I then figured maybe the controller had somehow been mis-programmed in such a way that is was powering up in sleep mode. This mode disables the I2C, so the only way to tickle it to life is to apply sufficient voltage to the SPEED pin.

I did this and then noticed the motor would attempt to start, just a "blip" and this would repeat every 5 seconds, and the I2C bus data lines went high. Hey, the 3.3V was back on.

The scope showed a lot of current draw just for that initial start before something in the controller shut it down.

I was then able to command the speedctrl register to 0 using I2C to stop the motor from trying to start. I then set voltage on SPEED pin to 0V and the 3.3V output stayed on. Yea!

I can read valid data from the status registers 0-8.

Now I though all I needed to do was re-program the EEPROM configuration values to known good values and I would be back in business. Here is where things are not working.

After sending the 0xC0DE value to the programming key register, I used to see that the eeReadyStatus would go high indicating I now had access to the config registers.

eeReadyStatus never goes high after sending 0xC0DE access key. So I tried every possible value 0x0000-0xFFFF and not one of those values ever results in eeReadyStatus==1

I'm at a loss as to what to try that might get eeReadyStatus==1. Until I can change the config registers, which are way wrong values, things are dead in the water.

I ignored the fact that eeReadyStatus was 0 and attempted to write the config registers with good values but they read back as the same wrong values.

Any ideas on what I might try next?  (Short of replacing the chip)

-Jay

  • 0
    TI__Mastermind 24405 points

    Hi Jay,

    Thanks for the detailed explanation.

    • Firstly, I would like to check if you followed the instructions in the Datasheet (8.3.6 EEPROM Access) to program the EEPROM. 
    • This issue could occur if the 3.3V on the device is noisy and bouncing around. Use an oscilloscope 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. 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. 
    • Finally, unsoldering the DRV10983Q1 on your board and putting it on the DRV10983Q1 EVM would help you track if the problem follows the device (which would eliminate the layout or components as the issue).

    Regards,

    Vishnu

  • 0 in reply to Vishnu Balaraj
    Prodigy 10 points

    Answer to your first question: "I was making adjustments to the configuration registers and saving to EEPROM and seeing that the new configuration parameters were successfully saved and being used." (Yes)

    Answer to your second question: "I can read valid data from the status registers 0-8." (I2C communications to the controller are working perfectly at 400kHz, the clock and data lines are transitioning from 3.3V to 0V very cleanly on the oscilloscope. When idle, the I2C lines are pulled up to 3.3V, using the output from the controller chip and it is not "noisy". So, bad signaling is not the issue.)

    In response to your third point: "Any ideas on what I might try next?  (Short of replacing the chip)" (If I were to de-solder the controller chip to move it to an eval board, then I might as well just solder a new one back onto my board and theoretically the new chip would respond to the EEPROM programming with eeReadyStatus==1)

    I have determined that the EEPROM can no longer be placed in the "ready" state to change the shadow registers (90-96) using the procedure outlined in the datasheet. I have spun up 6 boards using this controller chip, 4 are still working but 2 of them have developed this EEPROM problem now. How many times might I expect to be able to re-program the EEPROM before it becomes unreliable? I don't think it would be less than 100 times would it? I would expect it should be in the multiple thousands of times before it "wore out".

    The controllers have never been operated outside of the limits listed on the datasheet. They are being tested over the full range of values in the speed ctrl register (0-511). We use I2C commands to control the speed, not voltage or PWM on the SPEED pin.

    I was hoping that there might be some undocumented procedure using registers not mentioned in the datasheet that might be used to perform some sort of factory reset of the controller EEPROM and bring it back to life.

  • 0 in reply to Jay Smith
    TI__Mastermind 24405 points

    Jay,

    The EEPROM write cycle is 1000 for this device. The procedure in the datasheet shouldn't have any issues because we follow the same steps in our GUI and we could write to EEPROM.  , I'd recommend referring to the code as a reference (Link: https://www.ti.com/tool/TIDA-01373#support-training) . Look at the "TIDA-01373 DRV10983Q1_987 Example Code"

    Regards,

    Vishnu

  • 0 in reply to Vishnu Balaraj
    Prodigy 10 points

    Vishnu,

    Apparently you still do not understand the problem I am having. How do I convince you I do not have a software programming error?

    I will try one more time to explain.

    Since you pointed me to some code you say works, I will show you where in your code it will not work....

    Look in file DRV10983Q1_987.c at functions DRV10983Q1_987_eepromEnableAccess() and DRV10983Q1_987_waitForeeReadyStatus()

    Here is the problem...

    DRV10983Q1_987_eepromEnableAccess() sets value 0xC0DE in the EEPROM_PROGRAMMING_1 register to "unlock" the EEPROM. This is correct, agreed?

    Then DRV10983Q1_987_waitForeeReadyStatus() is reading EEPROM_PROGRAMMING_2 register over and over until it returns value 0x0001. Your code will be stuck in an infinite loop if it never reads a value of 0x0001 from that register, agreed?

    This is the problem I am having, reading the EEPROM_PROGRAMMING_2 register never returns a value of 0x0001. I have been trying to convey this problem from the start of this post.

    I have successfully reprogrammed the EEPROM with new motor parameters, (not even close to 1000 times yet) but nevertheless it had been working fine for me. At some point, the EEPROM became programmed with totally wrong values and now its eeReadyStatus bit will not return a "1" and I cannot fix the bad values in EEPROM. My suspicion is hardware failure of the DRV10983Q1 device. I cannot change the values in the shadow registers either.

    Suppose your code suddenly could not read a value of 0x0001 from the EEPROM_PROGRAMMING_2 register, what would you do to fix it? I mean, your code was working, right? I have tried many different things to try and revive the chip but have not had any success. That is when I resorted to asking you if there was something I could do that only you knew about.

    I have spun up 6 boards, 4 of which are still functioning but two have failed in this way. If there is no way to recover the device then it is back to the drawing board with a different device for motor control. I cannot afford to have this board fail so easily, I haven't even gotten to environmental testing yet. It has never been subjected to more than 1A since there is a current limit from the power supply set at voltage of 14V.

    I thought this device would be quite rugged since it's features state:

    • Qualified for automotive applications
    • AEC-Q100 qualified with the following results:
    – Device temperature grade 1: –40°C to 125°C
    ambient operating temperature range
    – Device HBM ESD classification level 1C
    – Device CDM ESD classification level C4A

    -Jay

  • 0 in reply to Jay Smith
    TI__Mastermind 24405 points

    Jay,

    Let me firstly acknowledge your problem and let you know that I FULLY UNDERSTOOD YOUR PROBLEM. The reason why I shared the code is for you to check if all the steps before the "DRV10983Q1_987_waitForeeReadyStatus()" look good. This device has been in the market for several years and the only reason for the eeReadyStatus to stay zero is due to noise on 3.3V power rail. Can you check if the VREG, V3P3 and V1P8 output looks stable without any noise? 

    I don't understand what you mean by "At some point, the EEPROM became programmed with totally wrong values". Do you know what these wrong values are? Can you read from EEPROM and share the data? 

    Regards,

    Vishnu

  • 0 in reply to Vishnu Balaraj
    Prodigy 10 points

    Sorry for the confusion, I felt like you were trying to tell me my code was the problem and I know that is not the case
    because this code has been working for a couple of months. Now it's broken because the status won't ever read 1 and I don't know
    what happened to cause this. I can't reprogram the EEPROM values.

    I don't know if these values are really what the controller is trying to use since I cannot get a eeReadyStatus == 1
    and load the shadow registers 0x90-0x96 with EEPROM values by writing 0x0002 to register 0x35

    Just reading regs 0x90-0x96 on failed board 1 gets 0x0B9, 0x00B9, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000
    Just reading regs 0x90-0x96 on failed board 2 gets 0x0B8, 0x00B8, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000

    Those values used to be 0x00B8, 0x1B3B, 0x0040, 0x008F, 0x3B0F, 0x3043, 0x076A after I was able to do a mass-read of EEPROM


    I set up the o-scope to monitor I2C bus which is pulled up using the 3.3V output of the controller chip.
    Trace 1 is data, trace 2 is clock, trigger on data going low.
    The circuit we are using is the same as the application design Figure 71 in the datasheet using the same component values.
    I made screenshots of the o-scope at the various steps in trying to do a mass-read of EEPROM into shadow registers at power on.
    In previous code, I did not perform the steps in file 3 and 6, these step were added when it stopped working and I discovered the device
    was powering up in sleep mode. I needed to wake to get the 3.3V up to use I2C commands, which I didn't need to do that before.

    How can I upload a zip file to you with the screenshots? (382KB) Insert won't accept any of the files.

    File 1, device is not powered, no voltage applied to the controller device
    File 2, device is powered, 14V applied to VCC, 0V applied to SPEED pin
    File 3, after 3.3V applied to SPEED pin, to wake it up, device is trying to run the motor every 5 seconds
    File 4, sending I2C command to set spdctrl register (0x30) to 0x8000, manual zero
    File 5, after setting spdctrl to zero, device not trying to run motor, looks pretty clean 3.3V
    File 6, after setting SPEED pin back to 0V, still looks good 3.3V
    File 7, sending I2C command to read register (0x08) and get device id/revision, reads (0x0102), expected value
    File 8, sending I2C command to disable motor driver, register (0x60 = 0x8000)
    File 9, sending I2C command to clear access code register, (0x31 = 0x0000)
    File 10, sending I2C command to set access code register, (0x31 = 0xC0DE)
    File 11, sending I2C command to read ready status register, (0x32), reads 0x0000 over and over, never gets a "1"


  • 0 in reply to Jay Smith
    TI__Mastermind 24405 points

    Jay,

    Did you try setting the shadow register by setting ShadowRegEn in address 0x35 to 1 and write 0x90-0x96 to shadow registers and spin the motor? By following this step, device should use the values programmed in the shadow register to spin the motor. 

    Did you upload any file? I don't see any attachments in your thread.  

  • 0 in reply to Vishnu Balaraj
    Prodigy 10 points

    Yes, I did try changing the shadow register values (before and after) setting ShadowRegEn to 1. The values I write to the shadow registers do not remain. In other words the values I mentioned earlier is all that I read back after trying to change them.

    In my last post I asked this question:

    "How can I upload a zip file to you with the screenshots? (382KB) Insert won't accept any of the files."

    The answer to your question is no, I did not upload any file. Again, this tool we are using would not accept the file I tried to upload. I could not paste or upload any individual png image file or a zip file of all the image files. I work on a government installation that will not allow outside access to my network so I cannot send you a link to download the files.

    By the way, I received back one of the bad boards after I had the motor controller chip replaced with a new one. That board is now working again, using the same firmware. It's looking more and more like hardware failure of the EEPROM on the chip. I will keep working with the other bad board if you think at this point it can be revived through software.

  • 0 in reply to Jay Smith
    TI__Mastermind 24405 points

    Jay,

    I'll get back to you tomorrow.

    Regards,

    Vishnu

  • 0 in reply to Vishnu Balaraj
    TI__Mastermind 24405 points

    Jay,

    At this point I can only tell you that the device might have been damaged. I see no other reasons for the eeReadyStatus to stay zero. 

    Regards,

    Vishnu

  • 0 in reply to Vishnu Balaraj
    Prodigy 10 points

    Hi Vishnu,

    After damaging another controller EEPROM I have figured out how it is happening.

    During re-programming of the micro-controller, the programmer resets the microprocessor before beginning to program.

    But there is a delay between the reset and actual programming which allows the microprocessor to start up again running code that was previously programmed. (Don't ask me why this happens, it's Microchip)

    My startup code reads the EEPROM values and compares against a set of coded default values and if they appear to have changed, then the process of programming the EEPROM with the new values begins.

    Our circuit uses a GPIO pin to control the voltage to the motor controller chip. During startup I set this output high to power the motor controller chip. When the programming of the micro controller begins (after the reset and re-start), that GPIO pin goes low, thus shutting down power to the controller.

    Just so happens that in a rare instance of timing, the motor controller chip is smack in the middle of re-programming the EEPROM when that power down happens, leaving the EEPROM in a fatal, nonrecoverable state. (Damaged.)

    Thought I would update you on this, perhaps the chip designers would like to know that this can happen.

    Either put a big warning about power failure during EEPROM writes in the datasheet, or maybe they would like to update circuitry to handle the situation.

    Thanks for trying to figure out what happened, I know you didn't have any of this power up/down information to go on, I only discovered that this was occurring today. I appreciate the effort (and the patience) you put in.

    -Jay