text: Q:
  
  bldc crashing after '0' cross detection
  
  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:
  
  duty cycly = 30%.
  the bldc looks for '0' crossing and finds it.
  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
  
  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?
  
  A:
  
  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.
  
  