I'm designing a BLDC driver (sensorless) using the the KL04 microcontroller. I am implementing a zero cross detection for commutation of the states. The flow I am implementing is:

  1. duty cycly = 30%.
  2. the bldc looks for '0' crossing and finds it.
  3. commutations done at that time interval after that. its then an endless loop.

The above steps are fine and I am detecting '0' crossing properly. I am using a BLDC with no load. Please note that I am hardcoding the software to make the PWM duty-cycle to be 30%.

Now I just attach a small load, a blade/rotor for the motor. What happens next is confusing.

The software detects the '0' crossing and then crashes. The oscilloscope wave is shown below

'0' cross detection and then crashing

It shows a correct '0' crossing. this happens at a small yellow spike. but then after sometime it crashes. Even the pwm is not shown in that channel.

Without the load/blades my motor takes about 1 amp and with the rotor it takes about 1.2 amps. Hence, we know a load is there.

Can any one explain where I am making some errors please?

  • \$\begingroup\$ Zero crossing of voltage or current? \$\endgroup\$ – Andy aka Nov 15 '14 at 17:45
  • \$\begingroup\$ voltage. i am just using a voltage divider. \$\endgroup\$ – Board-Man Nov 15 '14 at 17:48
  • \$\begingroup\$ if the duty cycle was 20% it would work fine with and without the rotors. it fails in rotors when its 30% duty cycle. \$\endgroup\$ – Board-Man Nov 15 '14 at 17:51
  • \$\begingroup\$ I'd say you will have to buckle down and figure out how to log and debug this. There just isn't nearly enough information to figure this out from here. My guess is that the load is unsyncing your detection, followed by a re sync problem. \$\endgroup\$ – Erik Friesen Nov 15 '14 at 22:11
  • \$\begingroup\$ Hello that wld not be the case as once I get zero crossing I am saving that commutation time and commutating at that time. I am no longer looking for fresh zero crossings. \$\endgroup\$ – Board-Man Nov 16 '14 at 9:33

This is just a shot in the dark, because there are so many software and hardware possibilities. Please don't vote "down" my answer, as I'm only trying to help you troubleshoot, even if I can't offer a sure solution.

From a software point of view it comes to mind that whatever processing is being triggered after the zero crossing is detection, is not always completing quickly enough to be ready for the next detection. You didn't say whether the 0 crossing detection triggers a hardware interrupt, or is simply sensed and dealt within a sampling loop. The interrupt methodology would almost certainly make matters worse if you didn't take steps to ensure the interrupt service routine (ISR for short) could not be interrupted again before completing. But even in a simple loop, it is possible for an error in program logic to cause a stack "blowup", if a subroutine can call itself to respond to an event (recursion) without some limitation. To test for things like this, you may have to add an LED or two to your system which can be programmatically controlled with very little overhead. This will allow you to do things like turn a LED on when you go into a routine, and off when you complete. Or if recursion is allowed, light the LED when a static limit counter is exceeded. At least this will tell you if it is always the same routine or point in the program you're getting stuck in. It can be a long arduous task to successively break a problem like this into possibilities, to finally isolate the problem code. But once you have something like an extra LED or two to trigger, you can slowly agin the insight you need to pinpoint the problem.

Now, there is also the possibility that there is an insidious hardware issue here. A rule of thumb for me (though its not always easy to know) is that the more random the nature of a failure, the more likely it is to be a hardware issue. Conversely the more predictable a failure, the more likely it is programming. Now you said 'after a while" it locks up and crashes. If this "while" is always 1.745 seconds (just an example number), then I'd suspect programming. But if its "anywhere from instantly to many seconds later", then I'd consider some hardware issues. For example, if the problem is truly load dependent, it may be that under load the motor is generating more EMI or noise spikes on the power bus, either of which could make its way back into your electronics or MCU.

Good luck, and I hope some of this helps.

| improve this answer | |
  • \$\begingroup\$ I will def not down vote it sir. Actually its the same all the time so even I felt its a case of software. Thank u all for ur tips. \$\endgroup\$ – Board-Man Nov 15 '14 at 18:44
  • \$\begingroup\$ Could you kindly shed some light on "noise spikes on the power bus". How is EMI reflected back into the power bus. I would like to understand the actual physics behind it. If you could kindly post a link or so it wld be very helpful sir. \$\endgroup\$ – Board-Man Nov 15 '14 at 20:03
  • \$\begingroup\$ regarding spikes. i am using mosfets that have inbuilt flyback diodes. shouldnt they suffice. \$\endgroup\$ – Board-Man Nov 15 '14 at 20:49
  • \$\begingroup\$ Its hard to say. Yes you'd be generating high voltage spikes without those built in diodes. But remember, diodes can't help you below their conduction threshold of about 1/2 a volt, and you ARE dealing with an analog circuit designed to detect changes near zero. See what I mean? Not saying this is your problem, but don't write it off too fast. Sometimes its useful to replace a motor with a similar resistive load, just to eliminate it as a problem, when strange "possibly" noise related problems appear. Is there a way you can adjust your zero crossing detection to be less sensitive? \$\endgroup\$ – Randy Nov 15 '14 at 23:07
  • \$\begingroup\$ Hello I modified my software to make the motor work as a stepper motor. I hard coded commutation intervals with almost 60% duty cycle. It worked fine. U suggest replacing motor with resistive low. It will not give any bemf as bemf is more of an inductive load trait. \$\endgroup\$ – Board-Man Nov 16 '14 at 6:12

Call me old fashioned and lacking in knowledge of these new fangled brushless motors, but isn't commutation meant to happen when the current falls thru zero, not the voltage. Any motor under load looks like a resistor mainly. The resistor represents power delivered to the mechanical load (and also losses in the motor) but, there is always leakage inductance and this is in series with the motor and leakage inductance can "appear" be very large on light loads.

This means current could still be a very high value when the voltage dips thru zero and without taking this into account you get energy released very quickly which might cause a spark and EMI this resetting your CPU.

Having said that, this mechanism sohouldn't cause tthe CPU to crash unless you have a poor PCB layout or poor breadboard.

| improve this answer | |
  • \$\begingroup\$ my cpu is not being reset. i am looking for a stall and restarting it. there is no reset per-se. i agree with the current part. but even with the voltage it should work and the waveform mimics the ones shown in app notes. its as if the bemf is neutralizing the voltage. \$\endgroup\$ – Board-Man Nov 15 '14 at 18:08
  • \$\begingroup\$ i am refering my code based on this thesis scholar.lib.vt.edu/theses/available/etd-09152003-171904/… here the bemf is measured wrt ground and not the virtual gnd. \$\endgroup\$ – Board-Man Nov 15 '14 at 18:14
  • 1
    \$\begingroup\$ Did you not say your "software crashes"? \$\endgroup\$ – Andy aka Nov 15 '14 at 18:15
  • \$\begingroup\$ Sorry. my mistake. \$\endgroup\$ – Board-Man Nov 15 '14 at 18:16
  • \$\begingroup\$ page 25-26 of the doc describes the voltage measuring approach wrt gnd. \$\endgroup\$ – Board-Man Nov 15 '14 at 18:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.