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.

DRV8305: Bringing DRV8305 out of standby mode?

Part Number: DRV8305
Other Parts Discussed in Thread: MOTORWARE, LAUNCHXL-F280049C, BOOSTXL-DRV8320RS

I've got a Piccolo F28027F connected to a DRV3805 and I'm having trouble getting it to behave normally after coming out of standby mode. When activated, the motor whines and has very little torque after coming out of standby.

I'm initializing the EN_GATE pin with

EALLOW;
GpioCtrlRegs.GPAMUX1.bit.GPIO6 = 0; // GPIO6 = GPIO6
GpioCtrlRegs.GPADIR.bit.GPIO6 = 1; // GPIO6 as output
EDIS;

And setting it to Standby with

GpioDataRegs.GPACLEAR.bit.GPIO6 = 1; // into standby state

I can see the current usage drop on a multimeter, so it looks like it's getting into standby.

But after bringing it out of standby, is when I have problems

GpioDataRegs.GPASET.bit.GPIO6 = 1; // out of standby state

Is there something else I need to reset to exit standby? Something in the PWM control maybe? Should I be initializing/controlling the pin in a different way?

  • Hi Cody,

    Can you ensure that WAKE > 3V, PVDD > 4.5V, and SLEEP bit = 0 (in SPI) before EN_GATE = HIGH?

    Doing a GPASET should be fine to set the EN_GATE bit.

    Thanks,
    Aaron

  • WAKE = 3.23V, PVDD = >36V, SLEEP bit = 0

  • Hi Cody,

    When you bring it out of standby, what are the status of the inputs INHx and INLx, and EN_GATE?

    When you say the motor "whines", does it spin, vibrate, make noise, etc.? Are you using Hall sensors or sensorless commutation? And are you using trapezoidal commutation or sinusoidal?

    Thanks,

    Aaron

  • EN_GATE = 3.23v, INHx and INLx are low.

    When the motor is running, INHx and INLx are noticeably different when comparing before standby and after coming out of standby. After, the pattern is irregular. The waves have varying amplitudes and durations.

    The motor does spin to the commanded speed (I think), but it's surging on a regular interval, maybe .5sec. It makes a whining noise while running.

    Sensorless.

    I think trapezoidal, just from looking at the scope on INHx. How can I verify?

    Just for reference, my program is based on Lab 10e from the InstaSpin Labs.

  • Hey Cody,

    Thanks for the details. 

    Are you using InstaSPIN-FOC? If so, this means you're running sinusoidal current (sensorless FOC), so you'll have inputs with varying PWM duty cycles, is this what you mean by irregular? 

    Lab 10e looks to be like it's the "Flying Start" lab? This may have to do with the source code of the lab and whether the drivers for DRV8305 have the compatibility to place the DRV8305 in different states, although it should be as simple as toggling states by toggling EN_GATE with a bit.

    I've never run this lab before, but did you identify the motor before or insert the motor parameters of your motor? Are you using the GUI or source code? 

    Thanks,
    Aaron

  • By irregular, I mean that comparing the wave when the motor runs before I've put the 8305 into standby, to how the wave looks after it's come out of standby, the two are visually different.

    Yes, I think that is correct. Haven't really had any major issues that we couldn't iron out until we tried implementing this standby stuff.

    Yes, I went through the motor ID labs and am using the user parameters. It's possible some of the parameters aren't quite right, but as I said, haven't had a problem so far. Using the source code.

    One other thought that I've had is that all of my custom code lives in a function that gets called in the middle mainISR(), and I'm wondering if there's a better place for that call to happen. I inherited this project from someone else, that's where they had placed it and I never messed with it. I might experiment with moving that function call and see if that makes a difference.

  • No change, when moving the function call.

    However, I do have another breadcrumb. When exiting standby, the nFault LED turns on.

  • Hmmm, okay. If the motor ID works, that's good. I can tell you that no one on our team knows how the source code of the flying start lab, so we may not be of much help. 

    May I ask if there is a reason you are implementing the DRV8305? Although we don't support MotorWARE (C2000 team may help), MotorWARE is a much older software development kit for older launchpads such as the Piccolo series (F2802x, F2805x, F2806x). If customers are trying to evaluate sensorless-FOC for a gate driver solution, we usually push people to evaluate InstaSPIN-FOC with the BOOSTXL-DRV8320RS (60V max gate driver) with the LAUNCHXL-F280049C (newer LP) via MotorControl SDK. This also includes a better version of the flying start lab (is09) that the C2000 team can definitely support. 

    Otherwise, it will be difficult for the DRV team to support this source code. 

    Thanks,
    Aaron

  • That was a decision that was made way back before I was on this project. I don't have a better answer than that. We're at the point that the customer has a custom unified board and isn't too keen on hardware changes.

  • Hi Cody,

    Aaron will get back to you next week!

    Thanks,

    Matt

  • Hi Cody,

    Let me forward to C2000 team to see if they can assist. Could you kindly provide source code, or at least the mainISR() function where standby mode gets called? 

    Thanks,
    Aaron

  • I can send it directly, but not post it on the forum. Per customer request.

  • I did some science and added this

        if (intoStandby) {
            GpioDataRegs.GPACLEAR.bit.GPIO6 = 1; // into standby state
    
            intoStandby = false;
        }
    
        if (outOfStandby) {
            GpioDataRegs.GPASET.bit.GPIO6 = 1; // into standby state
    
            outOfStandby = false;
        }

    So I could manually trigger standby mode instead of through my control logic. And I'm still getting an nFault when exiting standby.

    I don't see anything populate the SPI status registers for the nFault in debug, which I think just means that it's doing another read and clearing it before I see it come across to the debug console, correct? Is there a way to preserve the registers so I can see it?

  • The flying start function is independent of the inverter and hardware, and you can find the source code in lab10e in motorware.

  • Thanks for clarifying Yanming. 

    Cody, can you check two things:

    1) Check if EN_GATE is set for at least 1ms before toggling the PWM inputs to drive the motor

    2) Check which fault is occurring by reading registers 0x01 to 0x04. 

    It's possible that the charge pump may not be powered up completely before driving the motor, or else you'll hit a VGS fault from not having enough gate voltage. 

    Thanks,

    Thanks,
    Aaron

  • The drive doesn't get turned on immediately after trying to wake from Standby. My code goes to an idle state waiting for other things to happen. And like I tested earlier, I still get this nFault when I manually control EN_GATE thru the debug console.

    I don't have enough equipment here to watch the timing on the EN_GATE, nFault, and PWM pins to see what's simultaneously happening. I'll see if my customer can test that with their setup.

    The only 1s I have in 0x01 - 0x04 are VCPH_UVFL and PVDD_OVFL, but they don't set with the nFault. I think they get set during the internal startup checks, correct?

  • Correct, VCPH_UVFL and PVDD_OVFL should only be nFAULT toggles and not latches, so there shouldn't cause nFAULT. If you can at least have 2 channels and monitor EN_GATE and nFAULT, this can help determine if the device is at least reaching the wake state from standby if 1 ms elapses and nFAULT still doesn't go low. (assuming PWMs are not driven). 

    If nFAULT does goes low before 1 ms, this would be a good place to read the faults to help root cause the issue, whether its driver or code related. 

    Two more things:

    1) When the fault condition occurs, does setting the CLR_FLT bit help remove the condition, or does the fault reappear?

    2) Have you tried running the algorithm on a second board with DRV8305, and does the issue still persist? This will help confirm whether its a HW or SW issue. 


    Thanks,
    Aaron

  • 1) CLR_FLTS does not appear to have an effect and doesn't reset, which means the fault condition remains?

    2) I am seeing the same behavior on multiple boards.

  • Hi Cody,

    Aaron will get back to you on Monday!

    Thanks,

    Matt

  • I've tried a couple of times to implement DELAY_US() into my program, and could never get it to build. It always opened up a black hole of errors.

    Anyway, tried it one more time and now it's building with that delay. I now have

    GpioDataRegs.GPASET.bit.GPIO6 = 1; // out of standby state
    DELAY_US(1100);

    Instead of just the GPASET line.

    No change in behavior to report, and still trying to get my customer to scope the EN_GATE and nFAULT pins.

  • Hi Cody,

    We are still looking for other ways to resolve this. It appears to be a SW issue since the issue replicates on both devices. Best way to ensure delay is being met and determine if any other faults are appearing is to probe those scope pins.

    Let's back up a bit: we are using F28027F Piccolo device, MotorWARE, and BOOSTXL-DRV8305, and Flying Start lab (9b). How much has the source code been modified? If it has been modified a lot, then C2000 should support this thread as we do not have the expertise to modify if the program is in an atypical condition when taking the motor out of standby. 

    If the customer can simply use the BOOSTXL-DRV8305 without the LaunchPad and set WAKE = 1, PVDD > 4.6V, and toggle EN_GATE = HIGH, they should see the current on the supply increase by a few milliamps to show the current going from standby to operating state. If this can be seen without nFAULT going low, then the device is working normally. 

    If it does goes low, then we are looking at a H/W issue. If not, then it is likely a SW issue and source code should be shared. The only advice I would be able to provide then is:

    - Read back which fault is occurring by reading registers 0x01 to 0x04

    - Ensure nFAULT internal pullup from MCU is disabled, as nFAULT already has external pullup

    Thanks,

    Aaron

  • One correction, Flying Start Lab 10e, not 9e. Most, if not all of the 10e code is still there, it's just been added to get the control behavior that the customer wants.

    I'll keep after the customer to get them to scope pins. The guy I usually work with is on vacation this week, so I'm having to talk to someone else to get that done.

    Don't see any of the 0x01 - 0x04 registers changing when the nFault triggers.

    How can I verify the nFault pullup is disabled? Can you provide a line of code I can drop in?

    I'll try dropping just the into/out of standby code into the untouched Lab 10e and see what it does.

  • Hi Cody,

    I'll await your update on customer probing pins. 

    There should be a HAL layer source code file (hal.c or something similar) that initializes all the GPIO pins in the F28069M. Check nFAULT pin connection of BOOSTXL-DRV8305 to F28069M LaunchPad pinout, find the GPIO number, and look for that initialization in the hal.c file.

    Could you trying implementing into/out of standby mode for a simpler lab, i.e. the first lab like GPIO toggle or the motor identification lab to see if there are no issues there?

    Thanks,
    Aaron

  • Hopefully will get some scope results today. The customer is back from vacation.

    Here's a few things I've learned:

    1) Added

    GPIO_setPullUp(obj->gpioHandle,GPIO_Number_28,GPIO_PullUp_Disable);

    to hal.c in the nFAULT section. Tested into and out of standby, and.... no nFault light! Got excited, swapped batteries to charge, and went to lunch. When I got back and tested it again, nFault was back. Hmm, so something voltage related? Looks like I get the nFault when exiting standby if the battery voltage is >35.0V. Observed no nFault at 34.9V.

    2) Tested my standby code in the GpioToggle example, and no nFault when exiting standby.

    3) Still trying to run a similar test with a fresh Lab 10e. Fighting a bunch of build errors.

    I'm wondering if some of the voltage parameters in user.h are off. Since the GpioToggle example doesn't use user.h. Would this make sense?

  • Hi Cody,

    Aaron will get back to you tomorrow!

    Thanks,

    Matt

  • Hi Cody,

    One thing I realized is that nFAULT does toggle and a PVDD_OVFL warning appears in SPI when PVDD is over 35V when rising, so this may have been the case all along. Can you try a line voltage supply of 32-V and see if the system works correctly afterwards? This makes sense because when EN_GATE = 1, device out of standby mode but PVDD_OVFL probably continues to toggle to the point where nFAULT remains on. 

    For user.h, can you ensure that the full scale voltage and current is correct for the hardware used with the code?

    Thanks,
    Aaron

  • Looks like the battery has internal protection that cuts out at ~32.75V, so I can't really test that very well.

    user.h values are as follows

    #define USER_IQ_FULL_SCALE_VOLTAGE_V     (36.0)
    #define USER_ADC_FULL_SCALE_VOLTAGE_V    (44.30)
    #define USER_IQ_FULL_SCALE_CURRENT_A     (24.0)
    #define USER_ADC_FULL_SCALE_CURRENT_A    (47.14)

    These values fall into the "inherited from the last guy that worked on this project" category.

    The battery is 36V nominal, full charge is ~42V.

  • Hmmmmm, seems like internal protection should then never allow the battery to trip a PVDD_OVFL warning or fault if its not supposed to go above 32.75V.

    The custom board should have ADC scaled resistor dividers for the phase voltages and bus voltage, with a filtering capacitor in parallel with the low side resistor of the resistor divider. Check pg 234 of the InstaSPIN User's Guide below:



    Can you make sure these values are consistent with the 32-V supply and motor phase voltages?

    Thanks,
    Aaron

  • According to my customer, the diagram matches the board. But you're saying it's set for a 32V supply? Is this compatible with the voltage range on the battery we're using?

  • An overvoltage flag could happen since the min for PVDD rising is 32.5V. Is there anything preset in the code where if an PVDD_OVFL flag warning occurs in software that it automatically disables the gate drivers and triggers a fault?

    Can you explain what you mean by matching? i.e. do the calculations for the parameters in the customer's user.h file (from the calculations above) are consistent with the resistors/caps used in their ADC circuit?

    Thanks,

    Aaron

  • Hello Cody,

    I wanted to check in to see if you needed additional help on this thread!

    Thanks,

    Matt

  • Apologies for the delayed response, I've been getting pulled out other projects.

    The diagram matches the board was the response that I got when I forwarded that to my customer. He's managing the PCB design.

    We have not resolved the nfault when coming out of standby. For the moment, my customer's preferred workaround is the secondary controller on the board blips the reset pin for the piccolo when we have the system waking from standby.

    One point that really confuses me with this nfault is that we aren't passing this voltage check coming out of standby, but we do on startup. So what's different?

    Anyway, I suspect that the solution is somewhere in the relationship between the full-scale voltage and current values in the program, and the physical circuit. I haven't been able to locate anything that really resembles a tutorial on how those full-scale values should be calculated. They're leftover from previous incarnations of this project.

  • Hi Cody,

    I suppose that startup beings the part up from being basically OFF, and as the part is going through the power-up state machine the nFAULT pin is held low. When coming out of standby, the part is not completely shut down, and therefore the power-up state machine is not executed, or at least not executed in the same way.

    Thanks,

    Matt

  • Hi Cody,

    Do you have any further questions on this thread?

    Thanks,

    Matt