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.

DRV10987: Can't get the driver to spin the motor -- OverCurr / Lock0

Part Number: DRV10987

Yes, the software curr limit is lower than the hardware limit.   

Yes, OpenLCurr is set below my software current limit.

Yes, I have the unit restricted to open loop. 

It would be best to work with someone one and one because the complexity if the part is pretty significant and we could be going back and forth with Q & A for weeks here on a written forum.

Doesn't TI offer direct support for real engineering products?

  • I'm also seeing a strange anomaly in the Supply Voltage readings.   When I start and stop the motor by I2C command and I continue to read all the values from the first 7 addresses -- the Supply Voltage starts out correctly at around 12.35V -- but when I start/stop by I2C command, I get higher voltage readings with can't be correct.   That voltage level reading returns to a correct output when I reset the entire board and the driver chip reinitializes.   Not sure why I'm seeing this strange behavior.

  • Keith,

    I have assigned your post to the device expert and they will get back to you tomorrow.

    Regards,

    -Adam

  • Thank you.  I'm pretty close to getting this thing going.   I just need a heavy hitter to take a look at advise me.

  • Keith,

    I don't see anything wrong in the schematic. Can you share the EEPROM register settings and the Motor spec?

    Do you read the Supply voltage from the device via I2C and see the variation? If so then how much variation you see between the actual Vcc and the Vcc read from the device? Is your power supply set to a lower current limit? Voltage could sag if the power supply hits the current limit when you turn on the device.

    I would recommend you to look into the following documents.

    Regards,

    Vishnu

  • Every line output in green is a fresh read.   When I have an error - I clear the fault register.

    Yes, I read the supply voltage with I2C.    Some variation is seen right in that picture with the print statements.  0x69 is 12.35V.

    HOWEVER, I found a big problem today.   My motor is 24V.   So, that might be the whole problem.    I need a day to mod the board and try all this again.

    I'd like to stay with this post to iron out all my issues.

    Thanks.

  • Just converted the voltage to 24V.    No change in results.

    I also went through my Kt calculations -- my constant came out to 4.80mV/Hz.   That seems a bit on the low side -- but I'm pretty sure I did the observation correctly.

    My motor is not easy to turn by hand -- I used a drill on a moderately low speed and took measurements and did the math.

    Here is my motor spinning process  

  • Here is a fresh set of readings.   All the motor variables can be seen here in the readout.     I have my fingers on the armature of the motor -- and there is just nothing there.

  • The resistance between 2 poles is about 6 ohms.   I divided that in half and plugged in the appropriate resistance.

  • Looks like I may have another problem.... I don't see any of my values from EEPROM being restored to the shadow registers on cold boot.   The software sees the config registers in a default state.    Based on the docs -- I assume that EEPROM restores values upon startup.    So perhaps my problem is that I'm not getting the values stored property and in then they are not active in the system?    I am certain that I can read all the values from the Config registers.

    The documentation is very shallow on an explanation on the shadow registers -- and there may be confusion on what you mean by enabling them for use or not for use?   Perhaps I need to add a routine that prints out all those registers also -- and makes sure those bits are set correctly also.

  • Here is my initialization process.   Is the EEPROM writing and reading done with the correct assumptions?    I'm not clear about how to work with the eeRefresh bit in Register 35.    Do I need to trigger the eeRefresh with that bit?   Or can an entirely new EEPROM read also update the config registers as well?

    // Initialization Path:
    //
    // 1) Get a handle for I2C Request Queue (established ablity to send/receive through I2C)
    // 2) Restore system values from nvs (51 values for all config register values)
    // 3) Check the bounds on those values
    // 4) Set speed control to I2C and set speed to 0 (standby mode)
    // 5) Read and print Misc values (SpeedCmd, spdBuffCmd, AnalogLvl, Device ID, RevID)
    // 6) Read Config registers
    //
    // If Config registers match restored system then exist init process.

    //
    // Assuming values don't match

    // 7) Write Config registers with new system values
    // 8) Trigger an EEPROM write with mass access enabled
    // 9) Trigger an EEPROM read with mass access enabled
    // 10) Read Config registers again and compare to system values

  • Something is undisclosed about the process by which the EEPROM values populate the Config registers upon startup.

    I assumed that the Config registers are automatically refreshed when power is applied -- or did I miss something in the documents?

    Must we trigger a Config register update through the eeRefresh bit?  (1: Sync shadow registers with contents of EEPROM)

    If not -- under what specific conditions is the eeRefresh bit used?

    Come on people where are you?   Projects die when support is weak...   If I can't get this working the boss will ask me to look for another solution.

  • Keith,

    Here is the procedure to program the EEPROM.

    1. Power up with any voltage within operating voltage range (6.2 V to 28 V)

    2. Wait 10 ms

    3. Write register 0x60 to set MTR_DIS = 1; this disables the motor driver.

    4. Write register 0x31 with 0x0000 to clear the EEPROM access code

    5. Write register 0x31 with 0xC0DE to enable access to EEPROM

    6. Read register 0x32 for eeReadyStatus = 1

    7. Case-A: Mass Write

    A. Write all individual shadow registers

    a. Write register 0x90 (CONFIG1) with CONFIG1 data

    b. ...

    c. Write register 0x96 (CONFIG7) with CONFIG7 data

    B. Write the following to register 0x35

    a. ShadowRegEn = 0

    b. eeRefresh = 0

    c. eeWRnEn = 1

    d. EEPROM Access Mode = 10

    C. Wait for register 0x32 eeReadyStatus = 1 – EEPROM is now updated with the contents of the shadow registers.

    8. Case-B: Mass Read

    A. Write the following to register 0x35

    a. ShadowRegEn = 0

    b. eeRefresh = 0

    c. eeWRnEn = 0

    d. eeAccMode = 10

    B. Internally, the device starts reading the EEPROM and storing it in the shadow registers.

    C. Wait for register 0x32 eeReadyStatus = 1 – shadow registers now contain the EEPROM values

    9. Write register 0x60 to set MTR_DIS = 0; this re-enables the motor driver

    Regards,

    Vishnu

  • This is very poor help indeed.   I have already been through all your documents.   I do know how to read.

  • When you copy and paste instructions directly out of the datasheet -- are you proud of that assistance?    Do you consider this "out of the box" thinking?

  • Can you copy and paste the part of the document that specifically explains these 2 things:

    1) How to correctly use the eeRefresh?

    2) All the steps required to make an individual EEPROM Read/Write?

    Because I don't see that information in the documents.

  • Keith,

    You mentioned in one of your posts that "software sees the config registers in a default state". If this is true, then it means that your CONFIG register values are not successfully saved in EEPROM. This is the reason why I copied and pasted the EEPROM write/read procedure for you to make sure you followed all the instructions. Now, assuming that you read all the instructions, did you have any problem in writing values to EEPROM? One of the most common issues that we have seen in the past is that eeReadyStatus bit in step 7 will read 0. Do you see this happen in your case? If so then this could most probably be a layout issue. In DRV10987, EEPROM block is powered by 3.3V LDO. If this power rail is noisy or at low voltage, then the functionality of EEPROM block gets affected. Can you measure the voltage at pin 9 (V3P3) to make sure the voltage is stable and not noisy? 

    To answer your questions in your latest post, EEPROM data transfers to the registers after power-on so setting the eerefresh bit is not required. The procedure that is described in the datasheet has all the instructions for EEPROM read/write.  

    Regards,

    Vishnu  

  • I can't verify yet that I'm successful in writing to EEPROM.   There is conflicting information about what the default state is.    In one part of the document reset values are zero --- yet there is a table in the document that shows there are real values in those memory locations (Table 9).

    I'm reading zeros - which doesn't tell me much because I don't know if I'm only readying shadow registers or the real EEPROM itself.

    I have not been looking at the eeReadyStatus because the document doesn't clearly indicate any function for reading it.    I already did a document search and looked at those 5 occurrences.

    Please explain in more clarity --  is the eeReadyStatus bit set by the system and for what reasons?

    I have 3.28V on pin 9... but that doesn't indicate stability under operation.   I'll need to recheck my capacitor there and increase that if I suspect insufficient voltage stability.

  • My external capacitor for 3.3V is kind of far from that pin.   I did not prioritize that distance from the pin.   The voltage there could be less than ideal.

  • Can you detail the exact instructions needed to use the config register directly without the need for EEPROM?

    The datasheet is completely useless about using the ShadowRegEn = 1.

    I'd rather just use the config registers directly for operation.

  • The part number of the device that you are using is DRV10987SPWPR which means the EEPROM registers have the default values shown in Table 9. If you are reading zeros then you aren't reading the EEPROM register values. 

    eeReadyStatus is set by the system when the EEPROM is ready for read/write access. If this bit is zero then it means that EEPROM block could be at insufficient voltage to function normally. 

  • When the ShadowRegEn is enabled, I2C reads the values in shadow register and ignores EEPROM and by doing this, shadow register values are used for device operation. This is the only instruction. After enabling this bit, are you able to read back the shadow register values after writing to it? 

     

  • Of course...   I do look at the eeReadyStatus and it takes some time and it does read 1 before I continue... Sorry, I was thinking about the eeRefresh bit.

  • I did work this direction at the beginning -- but I did not have success with it.   I'm going to try this route again... now that my software is stronger.

  • I will change the layout on and move the 1.8V and the 3.3V capacitor close to the pins.    That is an easy improvement.

  • Writing the Config registers doesn't seem to work unless you go through an EEPROM write process. 

     

    When I write directly to the Config registers and then immediately read them -- they all read zeros.

    But when I try to do a normal mass access EEPROM write process -- the Config registers are holding value -- and I can read those values.

    Even if I set or clear the ShadowRegEn at the beginning -- writing directly to the Config registers doesn't work.  

    The EEPROM routine disables the motor and unlocks the EEPROM and everything else in that list.   Why would that process be successful for writing config register values but the direct write doesn't work?

    What am I missing here? 

  • Please let me know if there is anything that I can help at this point. 

  • I'm right here trying to get help ---  there is plenty of input on my part...

    Why are you asking if there is anything for you to do for help?

    Please continue with advice based on my observations.

    The datasheet doesn't go nearly far enough to cover all our needs here.

  • Have you personally written software for the DRV10987?    Have you personally been successful at writing values to the config registers directly?

    I strongly suspect that something has been omitted from the datasheet.    I believe your customers are leaning on the demo hardware units and the pre-packaged software tool that TI releases.

  • Hello Keith,

    This looks like it has been a rough experience; you’ve got every right to be frustrated.

    Before we get into debug steps, I’m going to see if I can explain the intended experience little bit more clearly.

     

    Shadow Registers and EEPROM: Basic

    The DRV10987 motor drive algorithm uses the values in the CONFIG1 to CONFIG7 section of memory to modify the algorithm behavior. To expand, when a user sends an I2C command, the values are put into this space—which we call shadow registers labeled CONFIG1 to CONFIG7. From a “configure and tune the motor performance” stand point; this is all the customer needs to do: send I2C commands to the shadow register space.

     

    However, the shadow register space is volatile memory, so we lose the contents of the space when we power down. As a result, the user would have to send many I2C write commands every time the device powers up, which is not elegant.

     

    This is where EEPROM comes in. On power up, the device defaults to copying the EEPROM contents into this shadow register region. If we programmed EEPROM beforehand, there’s no initialization needed, the user can immediately start polling memory spaces outside of CONFIG1 to CONFIG7 to get some information on the status.

     

    Programming EEPROM should only be used when the user intends to change the default loaded values on power up. If we’re debugging or tuning, only programming into shadow registers should be sufficient.

     

    Shadow Registers and EEPROM: Advanced

    I’d group the EEPROM Programming registers as follows:

    Important for “regular” operation

    • ShadowRegEn = 0x1, so they’re enabled

    • eeRefresh = 0x0, considered normal operation

    • (To your point) not in the register map, but 0x35[12] = 0b1, another way to enable (or disable) shadow registers. Since the user doesn’t know it exists, it should have never been changed but I have seen someone change the value unintentionally in the past. Why the creators didn't put it in the datasheet is beyond baffling, but we do have plans to add it to the datasheet in the next revision update.

     

    Important for programming EEPROM

    • ENPROGKEY = 0xCODE

    • ShadowRegEn = 0x0, so they’re disabled

    • eeReadyStatus = 0x1 for indications that no operations are occurring in relation to the EEPROM block

    • eeRefresh = Write 0b1 in this spot to simulate the process when EEPROM is copied to shadow register during power up. For whatever reason, this doesn’t reset to 0b0 once written to.

    • eeWRnEn = allows read or write of EEPROM

    • eeAccMode = 0b00 or 0b10. Pretty much only ever need mass access

     

    Not important for the basic use case or defined as advanced:

    • eeIndAddress

    • eeIndWData

    • eeIndRData

    • Other eeAccMode vaues

     

    I’m sure you’ll notice that the datasheet doesn’t explicitly teach any of this. It merely provides a list of steps to get the actions completed. Hopefully this explanation provides some more intuition for debugging the problem.

     

    Debugging

    Looking at this thread, you have:

    • Successful I2C protocol

      • i.e no NACKs

    • Both successful and unsuccessful shadow register access

      • i.e. read back shadow registers and get the values that were just written and at a different point in time read back shows a bunch of 0’s

    • Unsuccessful EEPROM programming

      • i.e. After power cycling, reading shadow register space doesn’t show the newly programmed values

    I’m going to guess that the EEPROM investigation lead to some of the advanced EEPROM settings being changed unintentionally. Read some of the registers and see if they’re set for intended operation.

    In addition, I see you have a few more spots to solder another DRV10987 to the board. Starting from a new device, that hasn’t had the EEPROM contents touched, might be a helpful step in the debug process. We can even send more samples if we need to.

     

    Next steps:

    We haven’t started talking about motor performance. So far, its been I2C commands, shadow registers, and EEPROM purpose (with some layout, and some prelim settings suggestions from Vishnu). I do have some recommendations on the settings you’re programming, but let’s take it one step at a time if we see some progress.

    I don’t want you to waste time on the performance if we decide the DRV10987 isn’t worth the hassle of continuing with.

    Let me know if you have any questions, Vishnu and I will get back to you as soon as we can.

     

    Best,

    -Cole

  • The datasheet can NOT have errors or vagueness in it if you are expecting customers to have success.

    You have expressed here some finer points about the ShadowRegEn and eeRefresh registers which were previously unclear to me.   I will add the changes to my routines here and see if this clears up my issues.

    I agree, no sense in talking about performance until we get past the basics. 

    Please correct the doc -- The number 35 should be where YY is.    This is a typo that is disruptive when you're scanning through the tables looking for your target register number.

  • I rather think that a complicated and slow EEPROM write process is not elegant.     I already must record all 51 motor values in my system NVS (can't easily access your EEPROM to handle that storage)... 

    AND -- I already go through I2C initialization for all my other onboard devices...   Why would I want to write extra program code to do the EEPROM storage when I already store those values?   It doesn't seem like any benefit to me.

    Now -- if my system was small and I had a real hard time requirement to be up and running fast -- then EEPROM storage on your device becomes more valuable.

    So -- let's just work the simplest route for now.   I only want to get access to reading and writing the Config registers and have the system pull values from there.  It's the simple choice.

    First:  I'll follow this route:

    1) Set (ShadowRegEn = 0x1, so they’re enabled)   (eeRefresh = 0x0, considered normal operation)

    2) Attempt a read and write of the Config registers...

  • Here is a full log of my attempt at writing/reading the config registers with ShadowRegEn = 0x1 and eeRefresh = 0x0.

    The write or the read failed.   I could have made a mistake but I don't see it....    Comments?

  • Previously -- I have seen the Config register hold values from an EEPROM write process which was flawed and never completely wrote to the EEPROM. (values were lost on cold boot) 

    SO -- I suspect that writing to the Config registers is much more like an EEPROM process.  

    It makes some sense that a motor possibly would not be able to update all its fundamental values without a very controlled shut down and restart...

    Here is what I suspect is going to work for writing to Config registers:

    1) Disable motor

    2) Write the EEPROM access code (may or may not be required)

    3) Wait for eeReadyStatus = Idle (may or may not be required)

    4) Write the Config registers

    5) Set Reg35    ShadowRegEn = 1 (allow remaining bits to stay 0)

    6) Wait for eeReadyStatus = Idle (may or may not be required -- but should work by default)

    7) Reset Reg35    ShadowRegEn = 0 (this is its default value on power-up)

    8) Enable motor

    Do you disagree with any of this?   Have you actually written the software yourself and can you give me the exact set of sequences that you know work?

    Who on this topic has actually written the software before???????

    K.

  • I went back to my EEPROM write routine and added in the eeRefresh = Write 0b1 that you recommended.   I get the same results are before -- the values can be read in from the config registers -- but are lost when I cold boot the system again.

    Notice that the EEPROMReg35 is cleared after EEPROM write / Config Read processes.

  • I have thought about going back to the board and changing out the part -- but I don't recognize any compelling reason that the part is not working.  I have very consistent communication without any errors -- and I'm reading all the data from the part in this above process with 00% accuracy.

    I still think we are missing something in the documentation... and we'll need to get someone on this support ticket with direct programming experience with the device.

    You both have admitted in this post and in others for this part -- that documentation is lacking in some areas.

    Everything about all areas of the software should be published and published accurately.   For example - there is almost no explanation of how to make a single EEPROM read or write.   I do see registers there -- I could guess how to do it -- but I shouldn't need to guess and burn up valuable time (mine and yours).

    Texas Instruments spent a lot of money in the engineering and silicon to make this product work -- and someone sabotages or squanders those resources when the documentation is unclear.

  • Ok.. ya ya.. I know I'm grumbling... I should probably retire.     Sorry.....  Let's figure this thing out and move on to better things...  Thanks.

  • Here is my update for today.

    My config registers were not getting updated automatically from EEPROM upon cold boot.  That is a fact.   I wrote a routine that stimulates the refresh that works consistently -- my Config values are updated upon every cold and warm boot.

    I also went through the trouble of testing out single config word writes/reads to/from EEPROM.   That works.   I can constantly write and read back values from each 16bit EEPROM word for configuration values.

    When I try to turn on the motor by giving it a speed command -- I still get nothing.

    So the next step here is the completely verify that I have all the normal open-loop variables set correctly.   I should be able to get this motor to spin in open-loop.

  • Here are all my system settings -- which are confirmed written into the device.

    Does anyone see anything obviously wrong here for just basic open-loop running?

  • This is how I invoke speed control on the motor and I monitor all the common values and faults.    I turn on the printing -- apply a simple speed value -- then turn off the speed value.  The motor does nothing -- no detectable movement.   No sound.... nothing.

    Where are experts?   We need the real engineers on this....

  • Hello Keith,

    Datasheet Errors:

    Agreed on errors, they have been documented and will be added.

     

    EEPROM Process speed:

    To add a little more context here, a customer’s manufacturing flow will usually have a step that programs EEPROM using separate hardware, not the actual system. So when the full system is actually assembled, it already has the correct settings stored in EEPROM. The assumption is that the correct settings will be on the DRV10987 or it would have failed the step in manufacturing. This means the Master FW can be a little less complex.

    This is why we created the EEPROM programming tool reference design, which you can find here: http://www.ti.com/tool/TIDA-01373. As we’ve already discussed, we don’t need to look at it now.

     

    Comments on sanity checks.

    I’d recommend checking SupplyVoltage (0x05[7:0]) because we can easily verify that number (which is expected to be nonzero).

     

    ShadowRegEn = 0x1 and 0x35[12]:

    ShadowRegEn is 0x35[12], this was my mistake.

     

    Comments on prior experience of programming:

    Yes, I’ve programmed this before. To be fair, it’s been a year since I had to develop code, and it’s clear my recollections and guidance have not been effective.

    Here’s my code for initializing the device:

    Looks like I decided to program the EEPROM on every power up. Note, I only used EEPROM Programming 5 for EEPROM write access enable and mass access enable. I never had to write to ShadowRegEn. After this write, you would expect EEPROM Programming 5 to read 0x1006.

    For now, I suggest your sequence should ignore lines 43 through 48 (i.e. skip trying to copy shadow register contents into EEPROM) and do not include anything else, besides reading EEPROM Programming 5.

     

    Comments on your progress:

    Can you verify that:

    • Step 6: Config register read: Are you just sending I2C read commands with addresses for Config1 0x90 to Config7 0x96 or are you using eeAccMode in combination with eeIndAddress and eeIndRData?

      • If you are just sending I2C commands with Config1, then I’ll need your answer for step 5.

      • If you are using eeAccMode, eeIndAddress, etc. Please do not use them for now and use the method above.

        • As mentioned in my previous post. The algorithm does not care about the contents of EEPROM, it will only look in the space of Config1 through Config7 (i.e shadow registers) to change the behavior of the algorithm

    • Step 5: Refresh config register from EEPROM is setting eeRefresh = 0b1

      • If so, please remove this from your sequence.

        • We already know that your current EEPROM contents are mostly blank. When you use the refresh, it will copy those zeros into the shadow registers

      • If not, can you please let me know what this process does

     

    Comments about Overcurrent.

    Assuming you’ve been reading Config1 through Config7 at step 6, we know that your shadow registers are populated with a phase resistance of 77m Ohm (or RValue = 0x8 and Rshift = 0x0). In open loop, the device calculates open loop current using I_ProgrammedOpenLoop * R_programmed/V_SupplyVoltageMeasured = %_SpeedCommand. So if the resistance is incorrect, we get the incorrect current.

    My notes show you actually have a phase resistance of 3 ohms with your motor. So, the device will attempt to apply almost 4 times the current you programmed. I can definitely see this hitting current limit.

    Again, the goal is to get the correct values in the shadow register region. Then I suspect for this problem to go away.

     

    Comments on VCC readings.

    According to your log we have: 0xCE is 24.2V, 0x9C is 18.3V, and 0x6A = 12.4V. You have to tell me if this expected from your system.

    I’m going to assume it isn’t and your target voltage is 24V, so we have two possible options:

    1. This is a real problem that is occurring the system when you program a speed command—and demand current from the supply

      • This can be easily checked with an oscilloscope probing VCC

      • When a voltage supplies drops out, it is a result of too much current. I’d recommend check the current limit or capabilities of the supply

    2. The VCC reading is wrong when the speed command is issued (which is a more noisy when the supply decides to pull current)

      • The VCC is measured by our internal ADC. Its very accurate unless something is interfering with ADC readings.

      • I saw that the caps schematic symbols on the V1P8 are bipolar. If they are, then you need to flip them the other way on the schematic

      • Otherwise, we need to look at your layout more closely

    This is multiple steps down the line, we need to get the intended values in the shadow registers before we start going down this path.

    Best,

    -Cole

  • I have to stimulate the system with Reg5 for my Config registers to be populated with data from EEPROM.  There is no way around this with cold boot starts.  I just can't read any values in Config until I do something with Reg5.   So, I do an eeRefresh with a full process (disable motor, write the code, wait for ReadyStatus, write Reg5, wait for ReadyStatus, enable motor).

    Other singular actions in EEPROM with Reg5 also stimulate a full refresh of the Config registers.

    I changed the resistance settings back to near a 3ohm value -- KtShift = 0x05, KtValue = 0x0A.   No change in behavior.

    I directly monitor the 24V supply line.   Voltage is steady and I see no increasing current draw on the system.

    I have no bipolar caps in the system... those are only symbols in the schematic.   All caps are MLCC.

    What are in the all secret register spaces?    Is it possible that I inadvertently wrote something in there which has impacted my system?   Or does all those spaces refresh to default states on a cold boot?

  • About those Caps.   The larger ones ARE polar, aluminum electrolytic.   Those are in the correct orientation.

  • Please understand - I felt that I could not incrementally verify a mass EEPROM write and the shadow register update all in one operation.    So, I wrote one EEPROM memory location -- and read one EEPROM memory location for verification.   In the process of the write and read, I saw that the shadow registers were updating -- which would be expected action.

    When I do nothing to EEPROM directly upon cold boot --- the shadow registers are not updated.   This is why I do the eeRefresh process.

    Your project always writes EEPROM in every cold or warm boot -- so I suspect this condition of empty Config registers would not have been observed in your test project.

    Typically, the best policy is not to try to write EEPROM when not required so the risk of burning out those memory cells is eliminated.

  • I went back to the code and applied all the default values which are specified in 

    Table 9. Default EEPROM Values

    but allowed for variations that applied to my motor and system.

    Still no results -- and the ADC values on the SystemVoltage are still all over the place...

    Now that I have pretty exhausted software options -- time to change the part out.

  • I have applied a new part.  I checked all the voltage rails -- 24V main, 5V, and 1.8V -- they look good at idle.  The part programmed as expected.

    With the updated default values we see the over-current error come on very slowly now... notice the ramp-up of the current reading.  We see a steady SpdCmd and spdCmdBuff values right up until the system declares an OverCurr condition.

    But - the System Voltage readings are still just all over the place.   Is this just a layout and capacitor problem?

    NOTE:  When I unplugged the motor and got the exact same results....    This motor has been tested on another power system and I know it works (24V 1/2Amp of power while running)....So what are you thinking??   Poor PCB layout?

    Clearly -- when we have an ADC problem -- we're not going to get the expected outcome....

    I'm thinking that I need to layout the board one more time (for capacitor layout changes) -- and then order one of your hardware kits where I can spin my target motor apart from my design work.

  • One more possibility -- I have a resistor in the 5V circuit which creates a linear supply.   It calls for 39 ohms.  I only had a 50 ohm part here.   Is that enough variance to throw off the circuit?   

    I just discovered another possible problem.. .you call for a resistor with a 1/4 watt rating.. .I'm short of that rating.   My part is smaller and is only 1/5 of a watt.

    Is the part sourcing current over that path?      That could be my problem there -- I need at least an 0603 and to be safe and an 0805 part in there...

    Between the higher resistance and the undersized part -- that is probably my ADC problem.