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.

DRV8353RS-EVM: How to use x1 PWM Mode

Part Number: DRV8353RS-EVM

Hello,

I'm currently using the DRV8353RS-EVM in order to evaluate its suitability for a project. Using the GUI and default firmware, I'm able to get x6 PWM mode to work using FOC but my end goal is to use x1 PWM mode with a motor that has hall effect sensors and I would ideally like to replicate this.

I attempted to do this in steps, first trying x3 PWM and x1 PWM mode (without sensors connected) but neither of these work - should these work in the default sensorless FOC configuration? Is there something I need to do other than change the SPI register? In x3 PWM mode, the motor barely moves, whilst in x1 PWM it tries to move but faults and my power supply current limits. If I could first get this to work, that would be great.

I'm aware the firmware is designed to be sensorless, however is there a way to imitate a sensored application without completely rewriting the firmware? I tried to connect the hall sensors to J3, placed 0ohm resistors at R48, R50 and R52 and then applied a PWM signal from a function generator at INHA whilst holding INHC low and INLC high (with the SPI reg set to x1 PWM mode). However, nothing happens. It's almost like it needs jump starting or the device doesn't recognise the input signals. There are no signals at the gate drive outputs. One theory I have is that the MCU is attempting to drive the hall sensor input lines at the same time as the sensors, causing the signals to never pass a threshold. I will try to uninitialise these pins from the MCU to see if it helps at all but any other ideas would be much appreciated as I may well be missing something fundamental!

Thanks in advance

  • Hello Sophia,

    Welcome to E2E and thank you for posting to the MD forum.

    1x PWM mode is quite different that working with the 6x or 3x PWM modes on the device. 1xPWM cannot be used for FOC control and it simply executes sensored trapezoidal control. You can use 1xPWM mode with an external controller or connected directly to the digital hall sensor outputs of the motor you are using. Note that these connections are made as follows:

    INHA, receives the PWM signal that determines the output frequency and duty cycle of the half bridges

    INLA= HALL_A, INHB= HALL_B, and INLB= HALL_C, if you do not want to use hall sensors you can use the external controller to identify the state of the motor via these pins.

    INHC connection controls the direction of the motor, if do not require to change the motors direction you can tie this pin low.

    INLC can be used as a break which turns off all high-side MOSFETs and enables all the low-side MOSFETs when its pulled low.

    Remember that the signal given to INHA is just a standard PWM, and yes make sure that the INLA, INHB, and INLB pins from the MCU are not attempting to provide signals to the device at the same time the hall sensors are connected. This will certainly confuse the device and may explain why the motor is not able to move, either because it is getting mixed signals when trying to go through the lookup table or the voltage is not meeting the proper thresholds.

    3x mode does work using sensorless FOC unlike the 1x PWM mode, but the amount of wires necessary to operate is reduced. In this mode you will only need to drive the INHx pins and if you do not need Hi-Z state for  SHx, you can tie the INLx pins high.

    I hope this helps and feel free to let me know if you have any other questions!

    Best,

    Isaac

  • Hi Isaac,

    Thanks so much for your response. That has clarified the use case of x1 PWM - I think I was misled by Fig 13-3 in DRV8353M 100-V Three-Phase Smart Gate Driver datasheet (ti.com) as it led me to believe the MCU could use FOC to drive the appropriate GPIOs but now I understand!

    I managed to fix my x1 PWM sensored problem by adjusting the default firmware to set those pins as GPIOs instead of PWM pins. As suspected, the MCU was driving these below the necessary thresholds. The motor now turns using the hall sensor inputs and a PWM signal. Changing the duty cycle proportionately adjusts the speed of the motor so we have success!

    Although I'm not in need of x3 PWM mode, I am curious as to why it doesn't work. Do you know if the default firmware the eval board comes with is capable of x3 PWM mode? Or would I need to adjust the firmware to use x3 PWM mode (possibly with the pin assignments again)?

    Thanks!

    Sophia

  • Hi Sophia,

    We will respond on this question early next week!

    Thanks,

    Matt

  • Hello Sophia,

    I am glad that you were able to get 1xPWM working on your system!

    As far as 3x PWM goes, if you left the connections as 6x PWM and just changed the the PWM_MODE register, as mentioned I believe the problem would be the pin assignments. The FOC firmware is most likely attempting to drive some of the INLx signals low at times accidentally placing the FET in a Hi-Z status continuously, which might be why the motor is partially working.

    One thing to note, is if you look at the truth tables for 6x and 3x they are slightly different, keep in mind that most FOC algorithms avoid the Hi-Z state in order to be more efficient, which means in 6x it could be avoiding using the state where INLx- 1 and INHx- 1, which is one of the non Hi-Z states in 3x PWM mode. Below is the truth table for reference:

    I personally have not attempted to drive a motor using 6x PWM algorithm with 3x PWM connections to see if it works properly but now I am a little curious to try out to see if it works. To answer your question to use 3x PWM to its full potential firmware modifications would need to be made in order to drive the motor properly.

    Best,

    Isaac

  • Hi Isaac,

    Okay yeah, that would make sense! If I get the time to come back to it I'll certainly try modifying the pins in firmware to get x3 PWM to work as it seems likely to be the problem. It's a shame the GUI/Firmware isn't documented slightly better to make it clear which features are/aren't available without modifciation. Thanks so much for your help though, you've added a lot of clarity and I can finally continue with designing my system.

    Cheers,

    Sophia

  • Thanks Sophia,

    Please let us know if you have any other questions or if we should close the thread!

    Thanks,

    Matt

  • Hi Matt,

    Please feel free to close the thread - I'm satisfied with the response!

    Thanks,

    Sophia

  • Thanks Sophia!

    Thanks,

    Matt