Issues with PAC5524 and BLDC (3kW) Motor Control in Lithium-Ion Battery Applications

I am developing a dedicated motor controller for the BLDC HPM3000B Model Motor (3kW with 48V) based on the PAC5524 IC. I am using Lithium Ion battery (around 57V fully charged).

My tests started with the evaluation board; however, upon the first trial of running the motor with the appropriate setup and GUI connection interface, the BLDC motor didn’t start, and the PAC5524 IC was short-circuited in several integral pins alongside the high-side MOSFETs.

I designed my controller similar to the EVK, and the first peripheral test worked fine, including communication interfaces, theoretical PWM signals, and good ADC readings. However, in the first trial of running the HPM3000B BLDC motor, right after the command “ON 6 step Trapezoidal” was pressed, the buck configuration stopped working, with the VP and VHM pins short-circuited, turning off the entire system, similar to what happened with the EVK. The only short-circuit component in my controller is the PAC5524, so I assume that some abs rating was abused when trying to start the motor (my guess would be the VP pin).

Unfortunately, I only saw the following comment in the forum after the controller was developed: The best choice for my application initially would be the PAC5532 IC. However, I would like to understand which ABS rating is being initially abused, when and how the Abs Max of the PAC5524 is abused, and if there are changes that I can make to make the operation of the motor selected with the controller design possible.

“One last note. The most I would ever recommend a PAC5523 to be operated at on battery based applications is 48V, assuming leaded acid batteries. If you are using Lithium Ion battery chemistries, and the nominal voltage is more like 50V to 56V, I definitely think you should only consider PAC5x32 devices as it would be very hard to ensure the PAC5523’s Abs Max is not abused.”

I would like to ask if there are more people who have encountered this problem and if there is any information that could be shared regarding the issue I am having. Thanks in advance.

Moreover, I was able to test a new scenario with the same controller developed but with a new PCB (new board, new components). In this scenario, I tried to run a 24V motor with a stable nominal voltage of around 36V. The motor didn’t start running; however, in these conditions, the ratings of the PAC5524 were not abused at first sight. However, while testing the firmware, the buck regulator stopped working, with the DRM pin now working at a 10kH switching frequency with a 1% duty cycle. This low value of the duty cycle only gives enough time for the inductor to charge less than 1V, not supplying the rest of the system, including the PAC5524.

It seems that no component or pin of the PAC5524 is short-circuited. Any information regarding similar issues is useful as I am trying to resolve them and explain why they are happening.

Hi Pestana2001,

Sorry to hear about your issues with the PAC5524. This device should be able to support 2-3KW applications, although the EVK is definitely not rated for such power densities. For 3KW you would probably need multiple FETs with very low RDSON and a much lower ohmage, higher power SENSE resistor. If I recall, the EVK has a 0.01 Ohm 3W sense resistor. That gives us roughly 17A RMS. Assuming the motor is running at 100% duty cycle with the 57V, that can’t go past the 1KW range. If the SENSE resistor is cooked, the AIOxy pins will see the high voltage and their Abs Max will be exceeded. Also need to point out that for 57 volts you are just too close to the device’s Abs Max which is 72V. Any transient will take the gate drivers and it is pretty much device destruction moving forward. As you had stated, the PAC5532 is THE device to consider for anything past the 48V mark.

I do have a series of questions with regards to your 24V/36V experiment as that should be well within what the PAC5524 can do. Is the motor running in sensored or sensorless mode? If you are using hall sensors, did you load the Hall Sensor Jumpers (JMP1/2/3 on position Hall Sensor)? Without it, the motor is not going to move as it is waiting for the hall sensor transition to decode an opcode. Without the jumpers, the opcode is 111 which is an illegal opcode so the motor can’t commutate. Can you share more information on which was the 24V you tried?

Some other questions:

  1. On your designed platform, do you have the DRSx clamps?
  2. On all of your experiments, did you ever saw the motor moving at all, or was it a complete lack of motion? Could it be that the motor stiction was too high and the inrush current was too high for either design?

I did take a look at the “HPM3000B” and such a large motor is definitely not going to work well with PAC5524. It is just too large. I would say that PAC5524 can probably go to 2KW and peak on 3KW for small periods of time, but this motor is rated for 2KW to 6KW. PAC5532, however, should be able to offer as much as 5KW. This is because on PAC5524 our gate drive current is 1A but on PAC5532 it is 2A. PAC55724 does have 1.2A source and 1.8A sink, but even then it will be hard pressed to go to much more than 2 KW steady state.

Hope the info helps!

Hi,

Thank you very much for the detailed explanation and the questions, which have greatly helped clarify some doubts I had.

Regarding the MOSFETs I’m using in the half-bridges, they are Infineon IPB039N10N3GATMA1. To answer your questions:

  • All tests on my board were conducted in sensorless mode, with the entire hall sensor interface disconnected (it wasn’t even soldered).
  • I’m using the DRSx clamps, but only directed toward the ground, as done in the EVK.
  • The PAC5524 documentation mentions it can handle a sink current of 1.5A for the gate drivers.

There was a complete lack of motor movement. However, the 24V motor made an attempt to move, as I could hear it, but it never actually rotated.

I will also conduct further tests to investigate whether motor stiction or inrush current could be contributing factors, as you suggested.

Once again, thank you for the help!