OEM driver Hall sensors

Hi Mikael,

I will need to review the schematics for this EVM on Monday, but on a custom-designed circuit board, you could choose to not use the integrated amplifiers in the DRV8301. You can connect both sense inputs to ground and leave the output pin floating. Then connect your senors to the ADC pins of the MCU instead. I think turning on DC_CAL could help. I believe the DC_CAL signal shorts both inputs to ground because it controls two pull-down FETs shown in Figure 6 of the datasheet. If you want to use the DC_CAL signal, I would assert that pin sometime before you start spinning the motor.

Let me review in greater detail on Monday.

Hi James,

Thank you for your answer!

I am beginning to think that this will not be possible or at least not an optimum solution.

What we have right now is 2 mosfets in parallel switching. They total to 400nC which is on the limits of what is possible for the drv8301. Allthough we are using only 12kHz frequency PWM. We are using these with a watercooled system and they should be good to deliver around 500A in pair. But I suspect we will need a bit more punch from the driver to push through bigger currents.

About the control pcb we made, the problem is that because of layout the current measurments from the shunts goes both ways to the drv8301 and via amps to the 28069M. Following the schematic of the EVM HC. But still, as I understand it after further reading, this shall not make the drv8301 throw a fault even if it's current measurments are off concerning the shunt inputs?

So, that tells me something else must be going on? I will do further investigation on monday. The odd thing is that during activation of the driver when running lab2b I can see the mosfets switch almost as they are stuck in a loop. All the identifying is done but with completely faulty parameters and a fault continiously outputted from the drv8301. And the motor never spins but is just whining a bit. Could this be because the gate charge needed to switch the mosfets is to big?

Another question. After designing with hall current sensors we removed the I-TOTAL summing opamp. As I understand I-TOTAL is not used by the control system, or am I wrong? If we need it, is there any other convenient way to calculate it?

Best regards,

Mikael

Hi Mikael,

What is the FET switching time you are trying to achieve? Using the 1.7-A gate drive setting, I calculated a switching time of 235ns for 400nC gate charge. Is that acceptable?

What fault are you seeing on the DRV8301? Can you read Status Register 1 (address 0x00) to see which fault the device reports? Are you using DC_CAL when you see the fault? If you do not use DC_CAL, and you short the sense resistors to ground, do you still see a fault?

I'm unfamiliar with this EVM, and I'm not sure why the EVM uses both external and internal amplifiers to feed back to the C2000. My guess is that it gives you options to try a 3-CSA setup or a 2-CSA setup. I've included someone from our C2000 team in case they have any comments on the setup and lab2b.

I'm not sure why the MOSFETS would get stuck in a loop. That sounds like it could be a C2000 issue. Can you use the debugger/breakpoints to see where the C2000 ends up when you see this error?

If you want a device without sense amplifiers, the DRV8320 and DRV8320R are our product offerings in that area.

the EVM has a path for using the DRV8301 2-ch PGA or 3 external amps. This is because in some cases you want to use all three currents and we weren't sure if this would work very well just using 1 external. When we designed the BOOSTXL-DRV8301 we actually just use 1 external OPA and the two internal PGAs on DRV8301 and it works well. The main thing with current sense (that the DRV8301_EVM does not do well) is to place the amplification as close to the MCU ADC pin as possible, use filtering on each input, and make sure to use Kelvin grounds for your current circuitry.

The MotorWare projects use the signal path for 3 external.

there would be no problem using LEMs instead. Make sure you update your hal and user.h files per the instructions in MotorWare and SPRUHJ1 for any changes you make to the current sense.

James, Chris,

Thank you for your detailed answers!

James, I am not actually stuck in a loop, the identification proceedes but ends up with an error "EST_State_Error". As soon as the identification process is done, the fault clears itself again. That is a bit odd, since in our previous driver hw when the nFAULT pin was asserted the pcb needed a reset and power cycling to dissappear.

Edit: After further investigating we are getting an over current from a shorted winding in our test subject. Our amplifier is not functioning well anyway, but at least it is behaving more or less as expected concidering. 

Chris, can you advice on the I-TOTAL question? Where the evaluation kit uses a summing op-amp to get the total current on the three shunt resistors, the LEM:s will not deliver voltages in the same format. Is this I-TOTAL used in MotorWare? Or is it just there for additional measurments on the total current consumption/trip point for over current situations?

I think other issues we see might be because we currently have the (LEM) current sensors on the motor phases. That will have to change from what I understand? The current sensors shall be in the phase ground path, correct? This is likely the reason for further issues we have right now. Are there any possible setting in the software for using the current sensors in the motor phases? I gues that we would have to convert all curents to positive values, for one. But I am not really sure where? 

Thank's!

/Mikael

I-TOTAL isn't used in the projects, but many customers do add this to monitor their bus current and add protection mechanisms into their system.

there is no issue in using phase currents, that is the preferred method for LEM type sensors. You still need to scale the signal to 0-3.3V with 0A at 1.65V and know if you are using a positive or a negative notation for the current. This is in the documentation.

We have scaled the hall sensors around 0A/1.65V with a range from 0-3.3V. This is verified. However, I'm still having issues with this. The problem definetely seems to be about the drv8301 now. The mosfets seem to suffer from shot through or similar. Even removing the parallell mosfet to decrease gate charge the problem persists. 

This is what the high side is doing after I enable and run the identification process, and at the same time the nFAULT is asserted;

And motorphases directly after drv8301 is enabled but not running looks like this;

Could this be a dead time issue, you think? I am out of ideas. It is worth a try, anyhow. I'll report back.

/Mikael

Also, note that my source voltage is 36V. As you see the high side pulses are way below that. Like if the bootstrap charge isn:t working as it is supposed to.

/Mikael

Mikael,

What are all the register values in the DRV8301 when you see this behavior?

Also, when does the nFAULT assert? Does it assert when the motor starts to spin, or does it assert earlier, like during the identification process?

I'm not sure if it is a deadtime issue or not. Have you tried different deadtime settings?

James,

The nFAULT is asserted as soon as the identification process starts, even before the Rs estimation. The motor makes a tiny jump and then it's all over. 

I suspect it is about deadtime, but not only. 

I did set deadtime to 500ns in MotorWare, and it did not really do much. 

I have an idea now that the gates are overdriven and depleat the gate current buffer, because of way to low gate resistance and a relative big gate capacitance of 10000pF. I will evaluate an increase in resistance next week. If that does not solve it we have just developed a new driver design, completely remade using three independent UCC27211 gate drivers instead. This will give us some more voltage headroom and twice the gate currents. Drawback is that we have no short detection, but we have a total current sensor that detect overcurrent if necessary. I am just not sure it will trigger fast enough if the currents are getting closer to 300A.

I will update the forum when I have a conclusion.

Best regards,

Mikael