BLDC problems with LPC1751

[lpcware]

Content originally posted in LPCWare by Tapio on Mon Feb 13 05:28:42 MST 2012
Hello,

I'm having problems using BLDC with LPC1751 and custom PCB.

A brief description of my project:
I made a circuit similar to app. note AN10898. I used same pins and ports as there is in the AN10898 so that I can eliminate as much as possible errors. Also fet driver circuits are similar. I have tested that electronics are ok by driving GPIO's up and down with systick.

I downloaded the sample code LPC1700_BLDC which is made with Keil. At first I converted it to LPCXpresso with no luck after programming my device. Then tested it directly with Keil.

The motor can be enabled by giving following values:

  /* Enable the BLDC motor */
  BLDC_Enable();
    PID_Motor.Brake = DISABLE;
    PID_Motor.Enable = ENABLE;

And this code above is written just before the while(1)-loop.

I'm just hearing a buzzing sound from the motor coils. I have tested my project with two differend EC-motor with the same result. And I know how to wire those motors because I have done that with a different motor controller.

By looking with oscilloscope, it seems that my motor controller is trying to start with no luck. There are single pulses coming to power mosfet gates. By single pulse I mean periodical pulse which is not pulse width modulated pulse (not a "large" pulse that consists of many smaller pulses). I haven't studied the code but maybe duty cycle of PWM is 100 % at start-up. Anyhow, it also seems that these pulses are almost at same phase with each others and it means that there is a risk that my fet bridge starts to heat even with no load (periodical shortcut). I haven't done any changes to the sample code, except now it starts automatically the motor when the device is powered up. I have also tested all variations with this set of code (in bldc.h -file):

/* Choose between HALL or QEI */
#define USE_HALL 1

#if (USE_HALL == 0)
    #define USE_QEI 1
#endif

/* Choose between MCPWM or GPIO interrupt feedback */
#define USE_MCPWM_FEEDBACK 0

So there is no difference between interrupt GPIO or MCPWM. I have also tried to give different values to p-term of the PID (10, 100 and 1000) and the motor won't start. In the function BLDC_commutate, I have also uncommented the line:

PID_Motor.mv = PID_Motor.Period/2; // Checks that PID isn't causing any failures

If I spin the motor with my hand to help it to start (to give an interrupt with halls and make it commutate the motor), there will be a larger shortcut in the fet bridge. Luckily I have 15 amps automatic fuse relay in the power line to prevent this kind of errors to cause any damage.

This sample code is made originally for LPC1768 so I'm just wondering if there is something that bugs me to use this with LPC1751?

Any suggestions how to proceed because I'm feeling a bit helpless? 

Thank you in advance!

BR,
Tapio

[lpcware]

Content originally posted in LPCWare by MiladAragorn on Fri Mar 18 14:58:12 MST 2016
According to the discussion above I tried all the possible ways from changing the PWM frequency to adding some delay in commutations in ramping phase, but still the motor doesn't move, I checked the connections so many times but still I don't know what is the problem. I think the code has been written in a very complex way and there are so many other ways to improve it, but before that I need to see something moves, would you mind helping me how you managed to move the motor beside the delay part?

Regards
Milad

[lpcware]

Content originally posted in LPCWare by Tapio on Sun Apr 08 07:21:05 MST 2012
Hello

Still having following problems after testing more.

When using the commutation sequence that was already implemented in the sample code I'm having heat losses. The motor starts to heat as well as the driver. Sometimes CCW direction even stops and starts to suck even more current from to supply. It sounds that there is something wrong with commutation or hall sensor interrupt.

I mean this part of the code:

/** Commutation table, connected to hall sensor */
volatile uint8_t CMT_tbl[2][8] = {    {0xF, 2, 0, 1, 4, 3, 5, 0xF},
                                    {0xF, 5, 3, 4, 1, 0, 2, 0xF} };

The  commutation sequence of the sample code should be ok by all means according all datasheets. However, when changing the sequence one step ahead the driver won't heat so much and the function of the motor is quite normal for both directions:

volatile uint8_t CMT_tbl[2][8] = {{ 0xF, 3, 1, 2, 5, 4, 0, 0xF },     
                                    { 0xF, 0, 4, 5, 2, 1, 3, 0xF } };    

Afters this change the motor still heats but not as much as before. I have checked that the GPIOs in the interrupt are having correct readings from hall sensors by rotating the motor shaft by hand step by step. I don't know what happens at fast speed; are readings still correct but I trust that they are (don't have logic analyzer at hand).  Also the wiring of the motor is as it should be. Otherwise it hardly would rotate at all. I have another motor controller with similar controlling method and it works just fine (no extra heating).

I'm running out of ideas, so anyone good suggestions what I'm doing wrong?

Just for additional information, I have converted the original library (AN10898) from Keil to LPCXpresso.

Thanks in advance!

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Fri Feb 17 05:48:56 MST 2012

---

Quote:

To calculate the PLL frequency: (fin * Msel)/(Nsel*2)

---

Unfortunately this formula isn't working in all cases :rolleyes:

With: F_cco0 = (2 * M * F_in) / N

User manual:

---

Quote:

The CCLKCFG register controls the division of the PLL0 output before it is used by the CPU.

CCLKSEL bit 7:0 Selects the divide value for creating the CPU clock (CCLK) from the PLL0 output.

---

So we get:

[COLOR=Red]CPU clock =  (2 * M * F_in) / N /(CCLKSEL_value +1)[/COLOR]

With standard setting: CCLKCFG_Val = CCLKSEL_value = 3

CPU clock = (M * F_in) / (2 * N) :)

[lpcware]

Content originally posted in LPCWare by NXP_Europe on Fri Feb 17 05:00:23 MST 2012
Tapio,

  Good to know you solved the problem.

  About the number of poles. An BLDC motor uses 6 step to make an electrical revolution for one pole pair, so each pole pair takes 6 steps to complete. If a motors has more than one pole pair it will need to commutated at a 6 x n (n = number of pole pairs) to make one mechanical revolution. So if a motor has 4 poles pair is takes 6x4=24 steps to make one complete mechanical revolution.
 
The frequency of the system in LPCXpresso is determined by a define on line 287 of system_LPC17xx.c: 
  “#define PLL0CFG_Val           0x00050063”
  When looking at the usermanual of the LPC17xx chapter 5.4 you can find that bit 0-14 are Msel and bit 16-23 are Nsel.
  To calculate the PLL frequency: (fin * Msel)/(Nsel*2)
  In the define Msel = 0x63 -> dec 99 but the register value stored is Msel minus 1, so Msel is effective 100
  Nsel  = 0x5 also minus 1 stored so effective 6
  This gives an effective frequency with the 12MHz crystal of (12 * 100) / (6 * 2) = 1200/12 = 100MHz
  To get 72MHz we could use (12 * 24) / (2*2) =  288 / 4 = 72 MHz
  Te result will be:
  “#define PLL0CFG_Val           0x00010018”

More details on how it works are in the Usermanual in chapter 4. The Clock generation of the LPC17xx very flexible in generating almost any frequency you want.

[lpcware]

Content originally posted in LPCWare by Tapio on Fri Feb 17 01:30:45 MST 2012
Guys,

Thanks for the support!

The issue seemed to be the ramping up. During the ramping up the motor in Call_1ms -function there is too fast switching sequense -> it just makes the motor buzzing. When adding a small delay between commutations  in the Call_1ms the motor starts to rotate. (Actually I realized the whole ramping up in different way but the point is the same).  And Rob, you seemed to be right, there is no function for the sixth commutation sequence. Except it puts the commutation pattern to  default: 0. Thanks for noticing.

About the PID_Motor -structure:

What exactly means poles in this context? I'm asking this because my RPM value seems to be about half of the setpoint.

Then one more question. The system clock is set to 72 MHz in this application (with Keil). If I convert this project to LPCXpresso it is 100 MHz. Since this is my first project with LPC-family I'm not familiar with registers, so could someone advice me how to lower the system clock freq. to 72 MHz?

Thanks.

Regards,
Tapio

[lpcware]

Content originally posted in LPCWare by NXP_Europe on Wed Feb 15 03:45:57 MST 2012
To get started with debugging it is wise to disable the involvement of the PID as this might give some strange behavior if it’s not working properly. This can be done by un-commenting “//  PID_Motor.mv = PID_Motor.Period/2;” on line 432 in BLDC.c, it’s part of the BLDC_Commutate function.
  Divide by 2 give 50% duty cycle, you might want to use a different value depending on your motor.
 
I suspect that the main cause of your problem is the polarity of the outputs. Check that your inverter stage uses the same polarity as the application note or it needs to be changed. This can be done on line 209, 219, 229 in BLDC.c.
  209->  “ channelsetup[0].channelPolarity = MCPWM_CHANNEL_PASSIVE_LO;”

  Chapter 3.1 of the application note describes how the setup of the MCPWM block is done.

[lpcware]

Content originally posted in LPCWare by Rob65 on Mon Feb 13 13:00:00 MST 2012
Just as a reference: we are talking here about the AN10898 PDF file (link) with the code (link).

Since you have already connected the motor to a different controller we at least know the motor is working.
Then of course the question is if it is getting the correct current - and what about the PWM frequency? If it is set too high the motor may keep buzzing.

The reason for the motor not starting I do not know.
As far as I could identify from the code, the motor is started in DC mode. This means that the software controls the MCO output directly without using the PWM modes of the MCPWM block. The outputs are set using the BLDC_commutate function.
As soon as the motor starts rotating (i.e. you are getting pulses from the HAL sensor), the PID block takes over and the PWM is being programmed. So if there is no action from the motor resulting in a moving rotor, resulting in a change in the HAL sensors, you will not see any PWM signals.
This means that the buzzing sound can be from either wrong wiring of the stator or wrong (or missing) wiring on the HAL sensors.

Which phases of the motor are being controlled when the motor runs is determined by translating the HAL sensor values into a step value for the BLDC_commutate function via CMT_tbl[][]. If there is any mismatch in the way in which the software think the HAL sensors or motor phases are connected, the motor will not rotate at all.
First start by verifying the connection of the motor coils, you can step through the different phases of the switching sequence (table 1 in the App Note) to see if your coils are properly connected. If that is OK, check the signals from the HAL sensors and see if that matches with the CMT_tbl translation (it translates the values read from the HAL sensors into a step for BLDC_commute.
If this all matches, the there is still the chance that the PWM frequency is too high for your motor coils to cope with.

Having a logic analyzer at hand will surely help.

You should also check the code.
Looking at BLDC_commutate I see that the steps are numbered 0..5, yet the Call_1ms loop in main.c Uses the values 1..6 and I am not sure if that is correct (the value 6 is not handled by BLDC_commutate).

Regards,[INDENT]Rob
[/INDENT]