Okay... So I need to run a 3phase BLDC motor from a 3phase bridge inverter. The PWM signals for the switches of the bridge need to be supplied from a microcontroller. This means I need 6 individual PWM outputs. Can this be done using the msp430g2553 20 pin variant? Also it'd be helpful if anyone can provide some code for the same.

It sounds like you're controlling the 6 inputs to the bride gate drivers directly from low voltage outputs on your micro.

What sort of PWM scheme are you considering? You could use simple trapezoidal PWM, in which case you could apply PWM only to the upper or lower drivers. If you're using basic sinusoidal PWM or SVM (space vector modulation, aka zero sequence modulation) then yes, you'll require PWM control on all 6 gate driver inputs and ensure an adequate dead time. Unlike simple trapezoidal PWM, sinusoidal or SVM control is not trivial to develop from scratch.

With trapezoidal PWM you'll give up some efficiency (power dissipated in motor phase coils that doesn't contribute to torque) but you'll have lowest switching losses, an issue in high power applications. With basic sinusoidal PWM you have highest switching losses, and can only generate a max phase voltage that is about 87% of your DC motor bus voltage. SVM is the most complicated scheme but gives you sinusoidal phase output without the max phase voltage limitation and lower switching losses than sinusoidal PWM.

One of the best discussions of these PWM techniques I've found is here, courtesy of Jason Sachs: https://microchipdeveloper.com/mct5001:start

What is your rotor position feedback mechanism? Are you targeting sensorless control with phase current or voltage sense feedback, hall sensors, or some other form of angular position sensing?

Are you planning to run a velocity control loop, torque control loop or both? What you are able to do depends heavily on what kind of feedback you are getting from the motor.

Without knowing more about your phase driver power stage, BLDC motor power level and position feedback type, and overall control policies, it is hard to make any concrete suggestions.

As CustomSarge already pointed out, there are so many BLDC control choices these days that it doesn't make much sense to develop a scratch motor controller of any kind, particularly around the MSP430G2553. There are many inexpensive motor control development platform choices from ST Micro, Microchip and Texas Instruments to name a few, that give you processors with specific hardware features for motor control and software to get you started.

I am guessing this is a personal or class project of some kind, in which case you are probably using Hall sensor inputs for position feedback and use simple trapezoidal PWM control to spin a low-power BLDC motor at a target velocity. In this case you'd have to track rotor position via Hall sensor inputs in real time to update phase driver commutation state, and also to make some sort of actual velocity determination (tachometer function) to run a velocity control loop. You'll probably use a timer interrupt to drive PWM switching and control loop updates. If you can't get an interrupt on Hall input transitions you'll have to poll them as frequently as you can. A little latency from Hall transition to commutation state change won't prevent you from getting a low power motor spinning, but the inefficiency will become a limitation at higher velocity and power levels. With simple trapezoidal PWM restricted to, say, the lower phase drivers, you won't have to worry about dead time because the upper/lower driver for a particular phase should never turn on/off at the same time. Your commutation logic should be stateful and should absolutely guarantee this.

If you are new to BLDC motor control it will be very instructive to take the time to make this work. This seems like a fairly aggressive class project, especially if a target control architecture has not been specified and/or the required control elements have not been covered at some reasonable level of detail. There is a lot involved in a scratch BLDC controller, even for a very simple solution.

I don't know about the MSP430G2553, but you can find example BLDC control software implementations based on other simple micros lacking specific hardware features for motor control. These may be useful to a point.

Thank You all for the overwhelming amount of response within a day! Coming to matthewbarr's comment I'm enlisting the info. you asked for Sir(pardon me if it's supposed to be Ma'am!)

1. PWM scheme is typical square pwm.

2. Hall Sensor feedback. The given BLDC motor has in-built Hall Sensors.

3. Speed feedback loop as main target is to achieve speed control of BLDC Motor.

4. HCPL3120 Gate Driver (Supply Voltage=5V). Current Sensor LA55P (not within       the inverter ; interfaced separately).

5. Motor ratings: 48V, 900W, 2000RPM, 4-5 N-m.

You Sir almost completely outlined my project at hand. Kudos to your experience and expertise! I apologize to all for being a little less elaborate in my initial post as I wasn't exactly sure if my post was ever going to draw attention. 

Yes this is a school project (actually a little more than that) and I am supposed to control the 6 inputs to the bridge gate drivers. The only catch: I can't exercise my own will regarding the micro-controller (not for now at least) My instructor has handed me this msp exp430g2 launchpad and that's about it from his side as far as help goes! I'm trying my best to familiarize myself with the micro-controller by going through the data sheets and user guides and while I've SOMEWHAT understood the timers and pwm part, it's not exactly easy to translate that into coding something like this! (not at least for a beginner like me)

So now that I've briefed you people about my situation (in sufficient detail I believe) what do you all suggest?

The minimum pieces you need to develop are a core control loop or loops, bridge (gate driver) commutation state decode from PWM and Hall state, an average current value from ADC samples, an average velocity value (tachometer) from Hall state transitions, and some sort of external control/status interface. Apologies for the length, I hope there is some useful advice for you here. You are working at a non-trivial power level and have some interesting problems to solve.

At the heart of this is a velocity control loop, PI or PID. (I'd code PID, note that PID with Kd=0 is PI.) Inputs to the control loop are target velocity and actual velocity, if all you have is a single velocity loop the output will be an update (+/- delta) to the current PWM duty cycle. You'll want the velocity loop to update (compute new duty cycle update based on actual and target velocities, update target PWM duty cycle) every, say, 10 or 20 ms. The updated PWM value ranges from +100% to -100% for bidirectional operation.

With a current sensor you have the option of adding an inner torque control loop, definitely PI. The torque control loop inputs will be target and actual torque (current), output will be a duty cycle increment. The outer velocity loop now computes and applies a target torque increment, creating a target value for the inner torque loop. This loop should have higher bandwidth that the velocity loop, you might consider running it 5x or 10x more frequently.

This is really a better system than a velocity-only loop that directly controls PWM, and is very commonly used. With a solid inner torque loop you have much better control over the motor, and you can enforce a hard torque limit via the target torque value.

You'll probably want to consider adding some exponential averaging to generate smoother and more stable (read less noisy) actual velocity and actual torque values. Be careful, too much averaging and you add delay to the actual velocity or torque feedback, and control loop stability becomes a problem.

With control loops and feedback working properly, you will have a throttle that goes from +2000 to -2000 RPM. This assumes you have a tachometer that combines velocity and direction, producing corresponding +2000 to -2000 RPM actual velocity values. (Actual velocity may exceed 2000 RPM, target should not.) The same is true for the torque loop, your actual torque values should go from, say, -25 to 25 A. Returning to 0 RPM can be problematic because 0 velocity detection can be tricky, and there can be a 0 current offset in a bidirectional current sensor analog value.

It looks like your sensor wants to produce a +/- voltage centered around 0V. I'm guessing you'll need to level shift and scale before going into an ADC input on your processor that is, say 0v to 2.56V or to 3.3V, so you'll have the "What voltage means 0A?" question to answer. You may want a calibration step to determine the 0 current ADC voltage in each phase instrumented with a current sensor.

Consider a hard limit on the +/- PWM duty cycle increment. For example, if you have a torque control loop that updates every 2 ms and you limit it to, say, 1% per update, it would take 100 updates (200 ms total) to go from 0 to 100%. If you immediately go from 0 to 100% PWM you get a large current spike. Likewise, if you immediately go from 100% PWM to 0 you quickly dump all the energy stored in the motor back into the bridge in the form of back-EMF. Both of these are potentially destructive situations to avoid! Ideally your control loops automatically achieve this by virtue of the selected control constants, but it is nice to have this additional limiting when bringing up and tuning the control loops. You can always disable it if you don't need it.

By typical square PWM I think we're talking about what is commonly called block commutation. You've got 2^6 possible bridge states, but there are 6 useful active states and an all off state. (There is also a braking state, but I'm ignoring that.) There are 6 valid Hall A/B/C states, each Hall state implies two possible active bridge states for applying torque to the motor at the current rotor position, one for forward torque, one for reverse torque. In general the bridge commutation state is a simple and direct real-time decode of the current Hall state and direction of target torque. Given a bridge state for block commutation, with no PWM you're always at full forward or reverse torque. You'll want to apply PWM to either the active lower or upper driver. Pick upper or lower, in theory you can go either way, one may work best for your bridge and current sense hardware. You'll toggle the active, say, lower driver according to the target PWM duty cycle and frequency. The upper drivers are simply on or off. It should be pretty easy to find diagrams and discussions of this basic Hall sensor decode and block (aka trapezoidal) commutation with PWM. What you'll notice is that when the A lower driver is active only the B or C upper drivers switch state, and when A upper driver is active only the B or C lower drivers switch state. Likewise with B and C. This is why you don't need to consider dead time as long as you always move between valid adjacent block commutation states.

Keep in mind that phase A/B/C (or U/V/W) and Hall A/B/C conventions can vary. Swapping and/or inverting Hall inputs can produce a rotational direction reversal, as can swapping motor phases. It's easy for this to happen, there's just so much symmetry everywhere.

I'm not familiar with the MSP430G2553 so I don't have much to say about obtaining current sense samples. You'll want to sample the active phase current at a high enough rate to get a meaningful number of samples for a particular bridge commutation state at max RPM. Again, exponential averaging can help smooth the value from the sensor, and beware of delay from over-averaging. It may also help to qualify samples with bridge state, eg. ignore current samples unless a phase is actively sinking or sourcing.

Hopefully your processor gives you a good way (eg. interrupt on input port xition) to detect Hall sensor state transitions in real time. You'll need this information to drive block commutation decode, and to develop an actual velocity. Building a good digital tachometer from Hall sensor inputs is not easy. Trying to quickly decide when you're not moving as opposed to moving very slowly is one problem, decoding the sensors such that you have good resolution at high RPM and don't wind up re-applying stale velocity information in the control loop at low RPM is another. You also have the "noise" problem where mechanical differences in Hall sensor and magnet positions and electrical differences in switching times and rise/fall signal delays means that at perfect constant velocity you see differences in A/B/C Hall input edge-to-edge timing. Also pay attention to the number of stator poles (N/S pole-pairs really) which gives you the number of electrical cycles (6-state commutation sequences) per mechanical revolution in your motor, important to obtain actual RPM from Hall sensor inputs.

Finally you need some sort of control interface. You've got a UART, you could send periodic RPM commands and return actual RPM and torque.

I suggest getting the commutation decode working first. Initially don't power a motor or run a control loop, just force a PWM duty cycle and Hall inputs, and observe control outputs to gate drivers, verify PWM control and correct commutation state for each Hall input and direction case. Now get the tachometer working, you can either apply artificial Hall inputs from somewhere, or attach your motor and find some way to spin the shaft at, say +/-2 RPS (120 RPM) and see what kind of velocity information you get through your control/status interface. At this point you can bring up the control loops, power up the bridge and try to make a motor turn. Work at low power levels (no load on the motor) until you are comfortable the control is well behaved. Again, limiting the rate of change of PWM duty cycle wrt. time can help prevent surprises, life can get interesting at your kilowatt power level. Bring up the torque loop first. You'll need to do basic PI tuning to make the loop stable and responsive without overshoot. With a low torque target you should be able to apply load with your fingers and slow the motor down while the applied torque remains the same. Then bring up the velocity loop, same tuning exercise. Enabling D in PID can help you control velocity overshoot but may not be necessary. You should now be able to apply load with your fingers at modest RPM and see power go up as the control loops maintains velocity.

I just want to add that today's commercial motor control solutions are far more sophisticated and elegant than a simple trapezoidal control solution.

It is common now to support sensored or sensorless operation, with sophisticated methods to determine initial rotor position in sensorless systems and start smoothly. Extremely efficient and responsive operation is achieved by field oriented control (FOC), which requires significant computational resource and high quality (high bandwidth, low noise) ADC current sense input. FOC computation is typically done in dedicated hardware (ASIC, FPGA) or on a processor with DSP support. Average velocity and current estimation fall out of the FOC logic, driven by A/B/C motor phase current sense input. Hardware support for SVM and other commutation schemes is typical.

So I think the simple trapezoidal control solution is a very interesting learning exercise and will produce a useful, working motor control function if done well. That said, there is quite a bit of distance between this solution and the current state of the art.

Write an ISR (Interrupt Service Routine) for a timer. Use a convenient pin and set it == 1 when you enter the timer, and 0 when you exit. For development, put in a busy loop in the ISR. (Note: when you compile the code, compile with optimization == 0 (-O0) because the optimizer might eliminate the code. The reason for the busy wait is because you want to look at that pin with an oscope. This tells you two things: you entered the ISR, and he timing - how long between the interrupt firing. That period is part of the ISR setup, but getting the period calculation can be tricky. Pick a number, measure, adjust. (hint: you know your target time, you know the test time and period value. the ratio will give you your desired period value. plug it in and re-measure.)

Take out the busy loop...

Find/calculate the minimum PWM low period for all 6 PWM outputs. (Could also use the min HIGH - doesn't matter, but be consistent.) Pick your 6 output pins. Now you can write your PWM outputs in the ISR. Hint: Each uses a counter that is the least divisor of the whole set, and is the timer period.

You can change the PWM count for a specific pin on the fly if the base count is global, but better to hide it's a global with a little function that abstracts it for you.

I am assuming you have access to an oscope. Your school should have a lab.

This process will teach you howto read the datasheets to the point you can write an ISR - a fundamental skill.

Keep in mind there are mask bits that will allow or disallow interrupts from peripherals...

Good luck && have fun!

Barring some compelling reason to "roll your own", I'd:

Take power requirements: max voltage & current, motor build: hall sensored or not.

> small power sensorless: buy a simple unit on Amazon

> bigger power, either type: A> buy same simple unit and swap output power FETs  B> find the best suited BLDC controller ASIC and build from there.

Coding a 3 phase H-bridge is not trivial. Available ASICs do all the heavy lifting, you just set parameter registers through I2C. I'm not saying don't, just recognize the end goal: get it done and move on or wanting an academic exercise. P.S. If this is a school assignment, asking for help and not mentioning it is poor form in my book.

Re: H-bridge drivers, there are some MosFET drivers which which will do that, including a dead-time in between switching.  If I remember correctly, they have an enable, and a high/low input.

You can use a timer ISR to bit-bang your PWM outputs. And if you always set each output pin, even if it is the same value as before, you can easily create deterministic code.

(Setting an output pin to 1 when it is already 1 (same for set 0 when 0) works just fine and actually simplifies the logic. See "Mealy machine")

However, if you can find chips to do the 3-phase, do so. I fully concur with the others on this. The only exception - in general - is if you are very cost sensitive, like with toys. However, I doubt your app is a toy.

I also concur with CustomSarge about if this is a class project. If you are a student, you need the practice of actually writing your code and solving your own problems. One becomes a good problem solver by (duh) solving problems. We would be glad to help give direction, but students need to do the work. We were there once. We are now here because we had to do the work.

We are also happy to help each other, because no one can be an expert on everything, so we are happy to help each other in giving direction for our specific areas of expertise and experience. "Don't do that" is very valuable. Plus, one should always try to learn new things - that is a characteristic of professionals.

I have done just that with an Arduino, though for a slightly different purpose.  2 independent  (3) interleaved PWM outputs (total 6 o/ps), with frequency and pulse width defined by (at present) fixed values.  ln time, those values will be supplied by another Arduino.  At present, it runs at about 100kHz

Thank You all for the responses. Sorry I was busy attending to my sister who fell sick all of a sudden and needed to be hospitalized. matthewbarr and mr_bandit's comments have given me some insight. I think I'm ready to get going now!