Lab 5a burns motor (literally)

I can't answer why your motor has burn but I can answer for this :

" I figured that somehow a coil (2 i guess) must have been powered for too long, but then why would the FETs be cool?"

The power in the coil is R*I*I, so if the resistance is high, the power will also be high. So for 0.41 ohms at 10A, the power is 41W (assuming 0.41 ohm is phase to phase).

So regarding the size of the motor, 41W could be very important. Regarding the mosfet, they keep cool because Rdson is lower thant the coil resisance (even if we add switching losses).

Regards.

Emmanuel

"resulted in my motor setting on fire"

Wow! I've never seen a BLDC motor on fire.  I've melted the phase wires before, but never flames!  That's pretty amazing.  The little hobby motors are self-cooled, so they can overheat REALLY quick at low speed, but if your motor was running very fast it should have helped.

1. proj_lab5a is torque control, meaning that as soon as you give it enough Iq_Ref to overcome the start-up cogging torque the motor will take off, and reach full speed no-load very quickly.

2. It is certainly possible that your current controllers are not tuned well enough for this motor at high speed. Did you change them at all from the default?

"gMotorVars.Ki_Idq long 1056095 (Decimal) 0x00AAB4@Program"

you need to change this to IQ24.  If you run the proj_lab05a.js script it will load the variables used in the lab with proper type set.

set this in user.h from now on:

#define USER_IQ_FULL_SCALE_FREQ_Hz        (4 * USER_VOLTAGE_FILTER_POLE_Hz)

please attach your user.h and let me take a look at some other items

Thanks for the reply Emmanuel,

The reason I mentioned the 10A setting & the cold FETs was essentially to dismiss the possibility of bad settings or a faulty gate driver being the cause of the problem. Probably could have been more clear with the values I posted, they were actually not for the bldc motor (which had considerably less impedance still).  - I am struggling to find a reason as to why a close to brand new (& tested) motor could burn with these settings, the motor is rated for very close to 30A continuous (not continuous per se, but 30A from the battery PWMd) so it makes no sense to me that it would burn with only 10A through it (I went back through the lab with my PMSM and it seems that the motor died during identification - at least it does not spin without a manual increase in the reference speed setting, so there should have been only a small current through the windings.) (-Also when I say 10A though it, I mean net from the battery I'm sure dropping 10A DC across a phase would probably set the thing on fire.)

Thanks Chris,

I had actually changed user.h to make sure I hadn't damaged the board - by running up a PMSM. Luckily quadrotors tend to have four motors so I have re-identified another motor and put the same settings I had in. I'm hoping you can see something amiss because now I can't get this motor to speed up at all, it just sits there jumping around in very (very) slow circles (the identified values are very very close to the old motor so that part is definitely working correctly) - yet I am reasonably confident the hardware is fine because I have run up the PMSM with no issues whatsoever. - I haven't put much time into troubleshooting this yet ( 2am here) so I have probably just screwed something up in the settings, hopefully/

* There was definitely flame out of the motor, but I don't think it was the coils (just a regular orange flame - no green/blue copper)  - would post a pic but there is not much to see but a misshapen rubber grommet, from the outside the motor looks like it's in good condition.

*The motor did not spin up at all, it jittered around (as it does normally while identifying or at very low ref speeds) until a plume of cancer inducing smoke and some fire came out at which point I pulled the plug and checked that none of the FETs were warm (knee jerk reaction for me now).

*I checked against IQ24 initially and it didn't match up  - although it was significantly closer than the decimal equivalent. I am definitely not calculating Ki correctly, although how I could mess it up is beyond me. Incidentally, what is IQ24 format, must have skimmed over it in the doc?

*Should I make sure that the motor runs smoothly upto a max speed before trying lab 5a in future? At about 13-14k I can tell that the controller is missing a few beats, but the speed will continue to increase if I set it higher-  i'm just not game to do it when it starts making funny noises.

5141.user.h

Hey Chris,

Wondering if you've had a minute to scan through my user.h?

- I found that the reason my motor wasn't spinning up (regarding my last post) was due to a dead battery. I charged this up and now my motor will spin for a ffew seconds at a few krpm then drop to zero for a few seconds and then spin back up.... not sure why this would happen? Guessing bad settings in user.h though I can't figure out what.

- Could you explain how my motor could actually burn? I can't understand it - I though that it should be able to sit locked rotor with the current setting I have? How fast is the limiting on the board? I have a fairly sizable Lipo running my motor but I've been thinking that I should swap this out with a bench supply since the short circuit current out of my lipo would be insane?

- I also saw the spreadsheet you posted on this forum and have entered my variables but didn't see anything crazy?

-Still cant figure out the ki and kp from lab 5 (using a PMSM) - the math just does't work out for? I know that I must be missing something ridiculous given the simplicity of the math? 

Thanks

Patrick,

Your Ls value is incorrect. It can't be nano henry. Lowest inductance will be single micru henry.  With the value you are using the FAST estimation will be incorrect.

I made some other changes...please try to re-identify.

for USER_IQ_FULL_SCALE_VOLTAGE_V set this to your bus voltage for low flux motors.  Use the spreadsheet please and follow exactly.

I wouldn't use lab5 calculations for the speed controllers. I agree that it's too hard to follow. I've requested that it be removed from the lab.  Experiementally tuning the motor at zero speed and then step response is better IMO, especially since you really won't know an accurate inertia.

Hey Chris - 

There is something really strange going on with my board. The board is identifying much higher L values (0.004391968) - which I think (judging relative to my PMSM & some of your forum posts regarding Ls  for these motors) is too high and must be inaccurate? -I initially thought this was good and a result of something you fixed in user.h but after the motor refused to actually spin at all (high pitched wine and then terrible sounds when it tries to ramp up) I went back to my user.h that used to identify at e-9H (and would allow the motor to spin) but when I identify with this user.h the same thing happens (L is identified at about 0.004H and the motor will not spin). I have also tried going back to a fresh user.h and changing just the essentials  (pole pairs and bus voltage) - I know this is ill-advised but this definitely used to turn the motor, albeit very poorly.

(I have tried everything here with two different motors as well & have tested both motors on six-step controllers)

During identification the motors used to do a few revolutions but that has not been happening. I thought that I must have killed a FET/ lost a phase somehow since the can would shake but never actually move more than a few degrees -  so I went back to the trusty PMSM to make sure it still spun up . It did but was unstable at about 1krpm ( i think it is the same PMSM you guys supply with the DRV8312-69M-KIT) - can't remember if this happened when I used to drive it or not but I am fairly certain that it wouldn't spin at all if the power hardware was faulty.... Next thought was that maybe the current sense gear is not working properly - no idea how to test that, it is obviously working somewhat (not really convinced there is a hardware issue at all but I am completely at a loss). 

At one point while using your user.h with the correct bus voltage range (from spread sheet) the motor did a few clean revolutions when identifying, but the identified Ls went back to e-9... it also spun really nicely when I set the run bit, better than I have seen it thus far, stable from 800RPM to at least 5k (betting it would have gone thrice that - ran very smoothly) - I turned it off before testing the upper limits to copy down the identified values and the next time I ran the lab it went back to a high pitched wine and shaking instead of actually spinning - and the identified values were back around .00x H... **This was not the first time I tried your user.h either** The time the motor ran nicely seemed to be random/ I hadn't changed anything (except power cycled the board) from the failed attempt before or after (the successful run)/

I really have no clue where to go from here - really appreciate any thoughts on what could be causing this/ is it possible something in CCS or the lab src is corrupt?/  Hardware issue /etc

Thanks - sorry for the rambling, hard to know whats important.

Settings from ss: (I tried flux est freq at 100/50/20 Hz) - 

The only other values I put in where USER_IQ_FULL_SCALE_CURRENT_A & Voltage

Patrick,

It may be that your DRV8301 board is damaged. It certainly seems like something is wrong on the HW side since the 24V NEMA17 motor is also having issues.  If you are hesitent to purchase another kit you can send me the motor (or if available on-line somewhere for easy purchase) and I will make sure all is well before you invest more time/money.

Are you using 14.8V for the bus?  I know the DRV8301 kit doesn't like a bus voltage that low unless you supply the 5V separately to J2. It can brown out the digital logic.  I try to keep the bus to 18V+ with DRV8301 EVM.  If I need to use lower voltage I go to the BOOSTXL-DRV8301 (6-24V, 10A).

This sounds like a better fit for your application anyways - maximizing voltage and current resolution is key to InstaSPIN-FOC -  and a lower cost investment.  You can purchase LAUNCHXL-F28027F and BOOSTXL-DRV8301 for $66 combined.  And we will be releasing a compatible 69M version of the LaunchPad in a  few months.

Patrick,

Also, if you like we could try to get on a webex and I could help you directly by taking control of your mouse and running CCS.  I don't usually offer this but I know you have spent quite a bit of time already....

ChrisClearman said:

Patrick,

Also, if you like we could try to get on a webex and I could help you directly by taking control of your mouse and running CCS.  I don't usually offer this but I know you have spent quite a bit of time already....

 

Chris, that would be awesome. -Anytime that suits you, i'll throw CCS on a laptop now(my internet at home leaves a lot to be desired). - I'll also try supplying the 5V separately.

Re the LAUNCHXL-F28027F and BOOSTXL-DRV8301, I have already grabbed an F28027F LaunchPad and have been waiting for the BOOSTXL-DRV8301 to come in stock for a few weeks now - I thought when I saw it that it was more suitable for my project. I've looked through all of the big suppliers and can't find it in stock? Do you know of any suppliers with stock (pressed for time) - 

Thanks

Chris, thought I should post an update on things after my days work. 

There is still something truly bizarre going on with the board but the good news is that the HW is fine when it operates and I have found a trick that seems to convince it to operate.... My 'trick', which makes absolutely no sense, is to power up the board and identify the motor - this usually fails (>90% of the time) with an Ls at e-9H  and if I try to run the motor it just wines and shakes (don't even bother trying if e-9 is identified anymore, seems to indicate the board is not going to work) - at this point I stop the motor (& set the appropriate bits to 0 first) and swap any two of the phases and (without power-cycling the board) re-identify which results in an Ls identified at ~0.8e-7H - almost 1 whole uH! There is no particular phase order (as in yellow lead to a/red to b/etc) that makes the board 'work' which there shouldn't be  but if I forego swapping the wires and just re-identify the motor the board won't identify correctly.... The only possibility I could think of for this behavior is a bad connection that gets knocked when I swap out the phases - I've checked the through-hole stuff and re-plugged the control card/ swapped USB cable and the same thing still happens --- thinking perhaps there is a crystalline solder connection somewhere /something similar - I don't know anything about re-flowing though and don't want to destroy the board/ and it's just a hunch. Only other explanation is a glitch in the matrix.

/I thought when this problem first started it looked like the motor only had two active phases so maybe the terminal block does not have a solid connection. Not sure what you make of this? - it really makes no sense at all to me.

When the board does run properly (pretty much always after I learnt the 'trick') I get very good results from about 500 RPM to about 8k.. The low end keeps getting better - this is without  tuning at all so I'm fairly happy with this. Ill attach user.h if you wouldn't mind taking a glance, I've changed FLUX_EST_FREQ to 50 (ss actually says 100, should I just go ahead and kick it up to 100?) and the full scale current/voltage as per the ss.

This is the motor I am using - I think hobbyking are based in the states if you want to have a look at the motor/// Also, do you know of a motor in this class particularly suited to InstaSPIN? Are there brands with higher inductance's that make identifying easier? 

I'm still very keen for you to see what you can do with the motor by remoting in, unless it's a hassle for you- again, any time that works for you I can do (with a few hours lead)

Also looked into the LaunchPad booster further, it is definitely a far more suitable scale for me - if you know any suppliers/ probably makes more sense to email sales about this... which I'll do now.....

 Thanks

EDIT: When the board is not going to work, motor whining and can jittering, the identified values for Ls are either e-9H or 0.00XH - in either case, the failure mode seems the same, high pitched whining and refusal to spin..5355.user.h

Patrick,

Add as friend / message me with your contact information.

The BOOSTXL was supposed to be back in stock by now, I'll check on it. Our TI eStore will have stock the fastest.

Your trick isn't valid.  Until you have good parameters you won't have good control. The smallest flux you should see is maybe 2.0 e-6 H.  The EFLITE420 is 2.99 e-6 H, the second smalest I've seen.  This motor runs very well with the BoosterPack, but could run even better if you rescaled the ADC Voltage from the 26V full scale down to about 12 V full scale. 

This motor - and all hobby motors - are meant to be self cooled by the movement of the RC car or the helicopter blades though, so they do get quite hot unloaded, even when controlled well

Your motor should run just fine with the BoosterPack...but it is very hard to ID such low inductance with the full DRV8301 EVM though, the scaling is just so poor for small Vbus / small flux machines.

With your current hardware I think you should just be able to set the Ls value to 0.000003 and run the motor just fine though. You can do some testing, increasing the Ls value.  It is very likely to fall in the 2uH to 15uH range, and my best guess would be about 5uH.

You should have a good Rs measurement.  They are typically in the 0.015 range for these motors.  If larger poles / more torque you may see this up to about 0.2, but that is pretty rare.

Flux closer to 0.003 but up to 0.02 in larger motors like the EFLITE-700

Great Success!

Chris, using your best guess of 5uH and skipping identification has finally resulted in the motor doing what I expect. Taking the speed controller out of the equation results in the motor jumping to 15kRPM - perfectly, no significant heating or vibrations.From that, I figured the Ls/Rs must be in the ballpark, so I started playing with the speed loop PI tuning trying to get .5-15kRPM smoothly using the speed controller (I think this should be fairly attainable?) before moving onto some of the funner stuff like field weakening.

-Do you think I should be bothering moving the Ls/Rs values around while tuning or should I just be trying to tune Ki and Kp (spd)?

ChrisClearman said:

I wouldn't use lab5 calculations for the speed controllers. I agree that it's too hard to follow. I've requested that it be removed from the lab.  Experiementally tuning the motor at zero speed and then step response is better IMO, especially since you really won't know an accurate inertia.

Could you elaborate on this technique please. I've been following the guide in the lab for experimentally tuning the loop - zero reference speed and haven't had a whole lot of success with it. I see quite a bit of ringing that doesn't go away, though this may be normal with the controller tracking zero. I can set Kp so that I get a few seconds of oscillations after I spin the can (pull my finger along the can to make it spin/still set to zero speed) - then I increase Kp until the oscillations are minimal...

-Basically what I am doing is making sure the controller is giving a nice mechanical response at a speed reference of zero then spinning the motor up until I notice it becoming unstable... Lower Ki/ increase Kp until mechanical response at zero seems nice and repeat. Is this ever going to work (I am getting higher RPMs but I don't want to take Ki/p out of some sweet spot)? The speed controller is stable up to about 8.5kRPM.

Also, I want to setup the grapher in CCS to show Id/q like what is shown in the GUI- actually seeing the electrical response rather than looking/feeling the can would make things easier IMO? Id/Iq are expressions but they are always zero-obviously the MCU is getting them but they are not updating in the watcher?

ChrisClearman said:

Your trick isn't valid.  Until you have good parameters you won't have good control.

Thanks!

Great Success!

:)

-Do you think I should be bothering moving the Ls/Rs values around while tuning or should I just be trying to tune Ki and Kp (spd)?

No, do not touch Ls, Rs, or RoverL.  Just change the gains for the speed controller.  For these small motors the initial gains are always much too aggressive.  A good starting point is to divide both Kp and Ki by 10.

At zero speed - with ForceAngle Disabled - I simply tune the Kp for initial stiffness and Ki for spring/return/oscillation.  I usually start with Ki =0, get a good Kp, then start adding Ki. Sometimes needing to further modify Kp.

You then need to test this at various speeds, and various transitions from one speed to another.

Or, you could take the speed controller completely out of the equation and just have a torque controller...this is pretty typical for a helicopter where the user has a throttle.  You could even have a few "cruise modes" where you connect the speed loop back in.  All of this can be added in user system code.

Lower Ki/ increase Kp until mechanical response at zero seems nice and repeat. Is this ever going to work (I am getting higher RPMs but I don't want to take Ki/p out of some sweet spot)? The speed controller is stable up to about 8.5kRPM.

You can probably find a setting range with good speed control across the operating range when unloaded. Typically you wll have to reduce Kp to get good stability at higher speeds and give some away at lower speeds.  Once loaded though, in a dynamic application like this with a blade spinning it will be more challenging to have a single set of gains.  Typically 3-4 sets may be required.  Unless you use InstaSPIN-MOTION, in which case the SpinTAC controller can be tuned with a single gain and typically works across the entire operating range.  Makes things so easy!

Also, I want to setup the grapher in CCS to show Id/q like what is shown in the GUI- actually seeing the electrical response rather than looking/feeling the can would make things easier IMO? Id/Iq are expressions but they are always zero-obviously the MCU is getting them but they are not updating in the watcher?

Most of the variables you want have to be gotten from the controller using CTRL_getXXX or EST_getXXX functions.  Usually you will add this to background code like updating the gobal params.  In some cases you may need the values every control loop cycle, so you add inside your interrupt. Just watch your interrupt usage.

If doing a lot of data use the DLOG functions to store into a memory area.  There are examples of this in the InstaSPIN-MOTION labs.

Hey Chris, 

Spent the day playing with the PI loop trying to get 0->max(15k) with the speed controller in play. I have gotten a very nice response from the system for the range I tune it to... I have another problem at the higher end though (I think it is unrelated to the loop gains but I am not 100% sure) - at about 8-9k I notice that the system seems to almost miss a commutation point in the cycle (hard to describe but it is not clean) so I decided to increase  USER_PWM_FREQ_kHz  by 5k upto 50kHz, this resulted in the problem happening at about 7-8kRPM. Next step was to try the other direction - down to 35kHz which would let the system behave to about 10k... After some trial and error I have found a max at about USER_PWM_FREQ_kHz =18kHz which takes me up to 13.5kHz before I see the problem... I'm not sure if lowering the USER_PWM_FREQ_kHz is appropriate here (but it is effective)?
(Given that things improve by lowering USER_PWM_FREQ_kHz I figured that either I was missing interrupts due to AD conversions or maybe seeing some current clipping or something - upped the current limit in user.h which unsurprisingly had no effect - so it is not that)

-

ChrisClearman said:

Or, you could take the speed controller completely out of the equation and just have a torque controller...this is pretty typical for a helicopter where the user has a throttle.  You could even have a few "cruise modes" where you connect the speed loop back in.  All of this can be added in user system code.

Very tempting, taking the speed controller out makes things run so much better||maybe just simpler- going to talk to my thesis supervisor about this, would be very easy to justify and let me approach the project from a different angle.

Until my DRV8301 Booster arrives i'm going to keep trying to improve the speed-controller - incidentally, have you heard anything about when they should be back in stock? I opened up the 28027F labs and decided that loop gains and other user.h stuff should be directly portable - so the work is not in vain?

One more thing, I gave field weakening a run (without any loading/ torque data it is hard to see any results) and saw that lab(09) is lacking in information. Is there information somewhere about field weakening, specifically how it is applied by InstaSPIN and the expected results? 

Thanks for all your help so far!

Hello Patrick,

I have also seen "blips" during accelerations with speed control. Did you confirm that with Torque control only that you don't see this "blip", regardless of PWM frequency?

In my cases I've solved this by

1. reducing Kp gain, sometimes needing to reduce Ki.  Over the course of an application this is called "gain staging", having different gain sets for different operating points.

2. Using SpinTAC for the speed controller

I think why you see the RPM move is the time constant derived from the PWM frequency changing.  It is a strange behavior isn't it?

This has been my experience with the "blips", simple a speed PI issue. Anything that has to do with missing samples / bad samples typically occurs only at very high duty cycles and is consistent.  Yours sounds more like what I see.

The BoosterPacks have sold out twice now!  Amazing.  They are supposed to be in stock today, shipping against orders next week.  Make sure you are in the QUE.

Yes, the projects are completely portable. The only files that change are the DRV files (in next MotorWare these are being renamed HAL), all of the proj_lab## and everything in the /src folder for a solution are identical across MCU, inverter, and hardware.  That's the only way we could support this across as many things as we do!

"One more thing, I gave field weakening a run (without any loading/ torque data it is hard to see any results) and saw that lab(09) is lacking in information. Is there information somewhere about field weakening, specifically how it is applied by InstaSPIN and the expected results? "

This lab write-up hasn't been completed, but the SW is fully functional.  I have posted the brief instructions for proj_lab09 on here....let me see if I can find it rather than re-typing everything.

Hey Chris,

I've finally put a prop on my motor to test the possibility of leaving the speed controller out completely and just designing a torque controller in lieu (ETC?). Colo(u)r  me impressed, excellent (speed) stability, very fast ramp times and amazingly smooth/quick through zero speed transition, all with no PI tuning. I think I might write the speed loop in for start-up (minimum torque to spin up from zero jumps to about 1kRPM) but aside from that I'm just going to run as a torque controller.

ChrisClearman said:

I have also seen "blips" during accelerations with speed control. Did you confirm that with Torque control only that you don't see this "blip", regardless of PWM frequency?

-I checked this, the torque controller doesn't like being run lower than 45kHz, i.e. I see 'blips' in the torque controller when run at lower PWMs than 45Khz..

Something interesting I have noticed with a load on (prop) is that I get a higher top speed out of the torque controller than I do the speed controller. *By setting the motor current at 10A I see the speed top out at about 4.5kRPM with the speed controller and at about 6kRPM with the torque controller. Do you have any explanation for this, I couldn't explain it?

ChrisClearman said:

This lab write-up hasn't been completed, but the SW is fully functional.  I have posted the brief instructions for proj_lab09 on here....let me see if I can find it rather than re-typing everything.

Re BOOSTXL-DRV8301, is the 10A bottleneck solely a result of the FET, CSD18533Q5A, I have looked through the schematics and am thinking that I can probably just swap these with CSD18532NQ5B and claim 15-20A continuous.... I thought I would need to adjust the current sense HW but can't get a handle on how the full scale range is calculated (for the hardware)? In the Altium project, is the 'sense' sheet purely voltage sense? This is what I gather - and the current sense is done by looking at the V drop across R34/35/36 and feeding that into the DRV8301 gate drive ic? If this is accurate (?) would there be any hardeare changes required to swap the CSD18533Q5A with CSD18532NQ5B?

Thanks

Patrick,

"Colo(u)r  me impressed"

Excellent!  This is what is expected from InstaSPIN-FOC and FAST.

"all with no PI tuning"

Do remember that for this application you will likely want to multiply the defautl Current Kp gain by 4.  We divide the calculated bandwidth by 4 to soften the initial tuning to work across more motors.  Do some testing on your own.

"-I checked this, the torque controller doesn't like being run lower than 45kHz, i.e. I see 'blips' in the torque controller when run at lower PWMs than 45Khz.."

To be clear, you are only talking about the PWM frequency, not the torque controller frequency. Your current/torque loop should be at least 7x faster than your maximum Hz speed, and 10x is even better.  This is a standard rule of thumb for control systems.

"Something interesting I have noticed with a load on (prop) is that I get a higher top speed out of the torque controller than I do the speed controller. *By setting the motor current at 10A I see the speed top out at about 4.5kRPM with the speed controller and at about 6kRPM with the torque controller. Do you have any explanation for this, I couldn't explain it?"

I agree, this is very common. I have always chalked this up to to the speed PI saturating but I'm not 100% sure. I haven't gone through the steps of debugging this.  I would want to see if the Speed PI is saturating the output to a full 1.0, and verify the actual IqRef_A that is being used for the Iq PI controller.  I would also want to see if SpinTAC has the same issue...It is in my head that I tested this at one point and SpinTAC did NOT show this issue.  I would also want to test running the Speed Controller at the same rate as the current loop to see if it improves (I've had other users tell me it does, but I haven't tried myself).

"proj_lab09"

1. You can add NEGATIVE IdRef_A at any time. If you are operating at maximum speed already, and the speed ref is higher (or you are just using torque mode) the motor will go faster - with a reduction in torque. 

2. We also offer an automatic field weakening algorithm. The algorithm just adds NEGATIVE IdRef_A until the required speed loop is met. You can tune this PI controller that is used to set the IdRef. 

in both cases you yourself MUST insure that the total current stays below any limits required. Remember that Is = sqrt (Iq^2 + Id^2)

In cheap motors, if Is > maximum current you can very quickly damage and demagnetize the motor.

I'll have our friends from the DRV team answer your last question.

Hi Patrick,

The 10A rating is actually limited by thermal dissipation for the PCB. To handle more current would require either a heat sink, active cooling, or a different board. I would not recommend anything higher than 10A on this board without some form of heat transfer rigged up.

The C2000 takes in 7 ADC inuts. There are 4 voltages senses (1 for PVDD and 1 for each PHASE) through voltage dividers. You can see the PVDD sense on pg. 2 (MAIN POWER) and the PHASE sense on pg 4 (VOLTAGE SENSE). There are also 3 PHASE current sense. The current is measured on the low side of each half bridge through a sense resistor (pg 3). Two of these differential measurements are fed to the DRV8301 (pg 1) and 1 is fed to the OP2374 on pg. 4 (CURRENT sense).

Thanks Nick,

I'm doing up a board now, based heavily on the BOOST DRV8301.

Nicholas Oborny said:

The 10A rating is actually limited by thermal dissipation for the PCB

If it comes to it, would the heat sink need to be board sized or just large enough to cover the FETs? I'm planning on using the board exclusively on heli/multicopters so  there will be plenty of active cooling...except for bench testing, but I can tape a fan to it for that.

////////////

Chris, do you know if there is any particular reason that the fault signal from the gate driver is attached to SCI on the launchpad? I am thinking of moving this to another GPIO if it's not too painful? I was thinking of using some sort of comms -I2C/SPI/CAN/UART as a 'better' alternative to hobby 1-2ms PWM so I wanted to breakout the UART and I2C on my board... *In the source, where are GPIOs mapped? I could only find one register setting for fault but it must be mapped or at least used somewhere?

Thanks

Patrick,

I think it was just the only pin left.  All digital pins are GPIO, this one just happened to be assigned as one of the UART pins also. Since most aren't going to use the UART through the USB connection we decided to mux it in for our use.

"In the source, where are GPIOs mapped"

you need to introduce yourself to

C:\ti\motorware\motorware_1_01_00_11\sw\drivers\drv\boards\boostxldrv8301_revB\f28x\f2802x\src\drv.c

the drv files are the interface from all the core functions to the chip specific functions (like peripherals).

Some recommendations,

- Expand all of the power traces

- Lower Rds(on) FETs (these are pretty low already)

- High rated sense resistors (Power Rating)

- Size of heat sink depends on a variety of things. Does not necessarily have to be the size of the board.

- I think the main bottleneck on the BOOSTXL-DRV8301 is the heat geration of the sense resistors

- You can see a thermal shot of the BoosterPack in this blog. You cannot see the sense resistors on the back side though.

http://e2e.ti.com/blogs_/b/motordrivecontrol/archive/2013/11/05/motor-development-in-the-palm-of-your-hand-boostxl-drv8301-boosterpack.aspx

Chris && Nick,

I've done some work over the weekend and have some more questions if you(s) don't mind.

Software:

ChrisClearman said:

-

you need to introduce yourself to

C:\ti\motorware\motorware_1_01_00_11\sw\drivers\drv\boards\boostxldrv8301_revB\f28x\f2802x\src\drv.c

.

We had met.... I went back over this (&through 1000 'open declarations') and am pretty sure I now get whats going on... GPIO14 is setup as ePWM0,1&2's 'trip zone' trigger. So, in a nutshell, on event DRV8301 fault (GPIO14 high) EPWM0,1&2 are forced and held low and a system error is flagged? -If* i wanted to move FAULT from the current GPIO, all that would be required is to initialise the new GPIO as the trip-zone for ePWM0,1&2?

Re software current limits:

While running instaSPIN without the speed loop, I notice some instability at the upper end - with the quadrature current set-point at about 20A.  I have my #define USER_MOTOR_MAX_CURRENT    (25) which I am thinking may be clipping the output and causing the instability? I was fairly happy that the direct current was clamping to zero, but it is entirely possible that the net current is breaching the 25A limit. Would you expect instability if #define USER_MOTOR_MAX_CURRENT was being exceeded?

*By instability, I mean that the speed is not steady (the motor still turns nicely), sitting at about 5800RPM +- 200RPM. Also, said instability occurs at a point and does not get progressively worse as the quadrature current is increased. - Motor is rated at 30A, 1200kV and is being run from a 4cell lipo - loaded with a sizeable prop.

Hardware:

I'm doing my board in Eagle which apparently does not support net tie's. This should be no big problem,  X_ISENSE_P has been renamed as SL_X and X_ISENSE_N as GND. I would not worry about this except I noticed that X_ISENSE_N has been routed across the board to the ground pad of it's respective 1000pF capacitor (on ti's board). e.g. R45 on the opamp is routed explicitly to C33 and attaches to the ground plane here. Is there any reason for not just bolting R45 and C31 (et al) to the ground plane? (This is what I have done)

Re increasing board rating:

I have done some of the math behind the shunt resistors' ratings and limits and have come up with a seemingly too simple way to increase the current capacity. Basically, I want to halve the shunt resistance to 0.005R, allowing the op-amps (as is) to retain the 1.65V +-1.65V relationship to -20<->+20A and at the same time letting me lower the shunt resistor power rating to 2W/ (I2R). I would also replace the current FETs with CSD18532NQ5B - the footprint seems to be close enough to the Q5A that these changes could be dropped in to increase capacity of the DRV8301 BOOST. What am I not considering here (sure it's something)?

I'll go ahead and attach my eagle stuff on the off chance that management at ti loves employees spending copious amounts of time helping people on other continents (&screen shots don't have enough resolution to actually see 10mil traces)... or someone else wants something close to the DRV8301 BOOST in EAGLE. -The board leaves a lot to be desired in terms of routing, basically right now I just want something to spin a motor and get some data- next revision I should be able to optimise component placement - not ripping it up yet though. 

THANKS!

7450.FOC_ESC.zip 

"-If* i wanted to move FAULT from the current GPIO, all that would be required is to initialise the new GPIO as the trip-zone for ePWM0,1&2?"

yes. Of course, you need to make sure in HW that a correct input (from the DRV83x or in other applciations from a comparator or something) will actually control the Trip input.

"While running instaSPIN without the speed loop, I notice some instability at the upper end - with the quadrature current set-point at about 20A.  I have my #define USER_MOTOR_MAX_CURRENT    (25) which I am thinking may be clipping the output and causing the instability?"

When running in Torque mode the setting USER_MOTOR_MAX_CURRENT    (25) has NO EFFECT.  This variable is misnamed IMO. What it does is - when speed loop is enabled - it sets the Speed pid.maxOut  (translated into per unit).  So it's only the maximum allowed IqRef command from the Speed Controller to the Iq controller.

It is NEVER used in Torque only mode, and is never used for any sort of Is limitation.

1. Have you changed any of your current loop gains?  As mentioned, our default current Kps are a /4 of the calcualted bandwidth to make it easier to bring up more motors. For most motors you will want to add this *4 back in.  You can also do step response and tune these values even more precisely.

2. Is your flux variable steady at the various speeds?  If you see this rising as your speed set-point is increased this is due to a mismatch in the SW pole and the HW voltage poles.  On my BOOSTXL-DRV8301 board the flux estimation just ticks up with speed when my pole is at the default user.h.  I was able to "manually tune" by increasing this value until the increase was minimized and flux stayed reasonably stable

#define USER_VOLTAGE_FILTER_POLE_Hz   (390.0)  // (364.682) default valuewas too low

3. The real issue may be with current sense. Especially if you are near modulation transisitions the current reading windows get smaller, the cross coupling of switching noise gets worse, and is exacerbated by low inductance motors which don't have a nice decay during the high-side off / low-side on time.  You could verifty this by looking at the current readings and see if there are anomolies.

Patrick,

The reasoning for the net ties is to support a true differential connection. You do not want stray transients wandering into the current sense measurement from the GND plane. I would recommend 0 ohm resistors if you dont have net ties.

The BoosterPack current rating is restricted thermally by the size of the sense resistor. A smaller value sense resistor allows us to support a higher current range but we also lose resolution for lower current motors. We picked a happy middle ground.

Be warned, half the battle in getting a motor spinning is proper layout for critical signals (especially at higher currents). If you stuck close to the BoosterPack you should be fine. 

ChrisClearman said:

1. Have you changed any of your current loop gains?  As mentioned, our default current Kps are a /4 of the calcualted bandwidth to make it easier to bring up more motors.

Chris, spot on as usual. I had added *10 in for the current loops - confused current loop with speed loop multipliers when I dropped instaspin for a few days to do up a board. There is still some speed fluctuation at the top end but it is much better than it was. I'm putting this down to the fact that the motor was never identified - L&R are probably still a bit off which would put the loop gains out a bit?

ChrisClearman said:

When running in Torque mode the setting USER_MOTOR_MAX_CURRENT    (25) has NO EFFECT. This variable is misnamed IMO.

Agreed, the name is a bit misleading - found spruhj1c.pdf which goes over this well though.... slowly getting through the mountain of C2000 & instaSPIN docs. 

-This is probably in the aforementioned pdf somewhere but I can't find it...  How is the current limit actually set? I've been thinking that the DRV8301 might handle this on its' lonesome and just flag a general fault on over-current, meaning that it would be set at start-up via SPI?  - - My DRV8301 BOOST finally got sent, don't want to blow it up with my lipo by not setting the active current limiting/protection properly.

 

The reasoning for the net ties is to support a true differential connection. You do not want stray transients wandering into the current sense measurement from the GND plane. I would recommend 0 ohm resistors if you dont have net ties.

The BoosterPack current rating is restricted thermally by the size of the sense resistor. A smaller value sense resistor allows us to support a higher current range but we also lose resolution for lower current motors. We picked a happy middle ground.

Be warned, half the battle in getting a motor spinning is proper layout for critical signals (especially at higher currents). If you stuck close to the BoosterPack you should be fine. 

Thanks Nick, the differential connection makes sense - should have seen the 0R solution to the lack of net ties.

Still thinking about the best way to increase my board size - the loss of resolution is unavoidable with increasing current isn't it? I am using an EVM good for 40A, but it still uses the 3V3 12bit DACs on the piccolo - this means that regardless of the current sense setup, 40A is being squeezed into 1.65V unless i'm missing some ti trickery?

-Getting 2 boards fabbed so i'll just stick the bigger fets in with the .05R sense resistors and see what happens....

- My board is as close as I could get it to the booster pack although admittedly nowhere near as 'neat'. fingers crossed for success.

First, I want to correct something I've been espousing

1. Have you changed any of your current loop gains?  As mentioned, our default current Kps are a /4 of the calcualted bandwidth to make it easier to bring up more motors. For most motors you will want to add this *4 back in.  You can also do step response and tune these values even more precisely.

We were recommending this from initial launch to help at high speeds / high dynamics.  It was really a patch to help with the main issue of the actual angle changing significantly between the sample and the output.  This was solved (when you run the CTRL that is NOT in ROM) by our angle compensation
CTRL_angleDelayComp()

So, you should NOT need to change the default current controllers.  These are tuned based on the R, L, PWM, and control frequencies....so as long as these are all correct your current controllers should give excellent performance.

"There is still some speed fluctuation at the top end but it is much better than it was. I'm putting this down to the fact that the motor was never identified - L&R are probably still a bit off which would put the loop gains out a bit?"

Good starting point. Normally I would tell you that it's likely just your speed controller needs tuning at a different speed...but you are running Torque mode AND a very low inductance motor which makes it hard to ID.  Also, these low inductance motors are high current and can saturate (the Ls will decrease even more).  If you set Ls (close to) to the saturated Ls value at high current, your low-current L compensation is too low, but this is not a stability problem. The rotor flux and Rs is dominant anyway at low current, thus only a very small angle error results. At high current compensation/estimation is correct with this saturated (lower) Ls.

When this is the case, it is a very good idea to reduce your Ls parameter until you see stability at high speeds / high load.

"How is the current limit actually set?"

Look at the GATE_ functions

"I am using an EVM good for 40A, but it still uses the 3V3 12bit DACs on the piccolo - this means that regardless of the current sense setup, 40A is being squeezed into 1.65V unless i'm missing some ti trickery"

Yes, you are centering your 0A at 1.65, -40A at 0, and +40A at 3.3V

ChrisClearman said:

We were recommending this from initial launch to help at high speeds / high dynamics.  It was really a patch to help with the main issue of the actual angle changing significantly between the sample and the output.  This was solved (when you run the CTRL that is NOT in ROM) by our angle compensation
CTRL_angleDelayComp()

Chris, I'm running/modifying lab 5A for my ESC. Where/when should I call CTRL_angleDelayComp(). What do you mean by running ctrl not in rom, I thought the observer was exclusively run from rom? ... As lab5a is,  the efficacy of your *4 solution is indisputable :)

Thanks

Patrick,

CTRL_angleDelayComp() is already being called in ctrl.h CTRL_runOnLine_User(), which you are using.

_User means the majority of control code is in user memory (hence you have the source) while the estimator is still in ROM.

If you run just CTRL_runOnLIne() you are running the control code that is fully in ROM (on the F2806x devices) and does not have the angleDelayComp nor any of the svgen_current or overmodulation enhancments.

"the efficacy of your *4 solution is indisputable :)"

Can you please expand on this comment?

The 4 * Filter is a MAXIMUM value for the IQ_FULL_SCALE_FREQUENCY.  You should not get "better" results using the Maximum or any value lower.  Any performance benefit will be seen by tuning the user.h FILTER_POLE to better match the REAL HW voltage filter poles.  If these are very far off you will see the flux estimate rise or drop to nothing causing instability. Obviously if you already have a very low flux motor (like these small high speed hobby motors) you are more sensitive to the possibility of the flux change being a huge %.  Also, since the flux is so small you will have a larger dependence on the IQ_VOLTAGE variable - needing to insure you have enough resolution for the flux measurement.  So if you BARELY have enough resolution for the flux measurement, and then that flux drops below the value because your SW pole is too high, you are in trouble.

ChrisClearman said:

Can you please expand on this comment?

Why soitenly,

I finally got around to doing something with my rotary encoder so i've seen this empirically on an independent encoder as well as in the instaSPIN speed feedback. Without the *4 and using a 'clean' lab 5a I see some significant speed fluctuation at the top end (as discussed). The fluctuation does not look like ringing from a step response, it just oscillates a few 100RPM without ever dampening or going completely unstable.... The quadrature current looks like a textbook step response that does dampen (CCS grapher sample time set fairly low). Not sure if I should be expecting any sort of 'control response' from the speed since it is only being indirectly controlled?

Iq looks something like---with a lot longer dampening time without *4

   ___
  /       \     __________
 /         \_/
/

textbook

With the *4 in, the speed is much more stable and even tops out a little bit higher. Also, I think (not certain, been playing with encoder tonight) the motor is a little bit faster across the board with *4in... as in, Iq=5 equates to 3kRPM without *4 and with *4 maybe 3.1kRPM..... again, I didn't record any data so I can't back it up - bould be bs

I ctrl F'd though the c files in lab 5a looking for CTRL_runOnLIne() and couldn't find it - granted I looked for all of 5 minutes. Planning on doing some work on this over the weekend - hopefully I'll get around to not needing the *4.

PS. speed fluctuation only at the upper end.. Iq set point > 18.

C:\ti\motorware\motorware_1_01_00_11\sw\solutions\instaspin_foc\src\ctrl.h

CTRL_runOnLine_User

When you do some work this weekend

1. please try tuning your SW voltage_filter_pole to your HW voltage filter poles by monitoring your flux value for stability.  If flux is rising with steady state speeds increase your pole, if falling decrease your pole.  What we have seen is a consistent need to increase your pole in the ~10-20% range.

2. Once that is done, please see if you can duplicate any of the high end modulation issues just by changing IQ_FULL_SCALE_FREQUENCY between Maximum Frequency and 4 * FILTER_POLE.

Interested in your results because we have taken quite a bit of data and don't see any issues once the SW fitler is adjusted better.

Hey Chris,

Sorry for not getting back to you.... Crazy busy playing with DRV8301 boost (& identifying e-flite 420 with it - YAY) and building my own hardware (whoever came up with power pads should be shot!)... I have a tonne of speed data but I haven't broken out matlab yet so it's just a pile of text - I'll have to get back to this soon so I'll hopefully post some nice graphs (of unstable top end speed) soonish....

Right now I would be really grateful for some help with editing lab05 for my purposes...

On an F28027 I have written a routine to get the high time of a 50HZ pwm signal (So I can run instaspin from an RC tx).... This was not very difficult and I have just used GPIO12, Timer 2 and 2 interrupts (one rising and one falling edge of GPIO12. (I am trying to get this to work on the BOOST, not my own hardware, yet)

I did run in to some problems using TIs top level C (whatever the correct term is) for this so I am using direct register manipulation instead. eg 

TIMER_stop(myTimer2); --->>>CpuTimer2Regs.TCR.bit.TSS = 1;

 This is the only way I could get it to work - checked with a logic analyzer, all working well.

Porting to instaspin....

Firstly, I added DSP28x_Project.h (because of CpuTimer2 etc) and no other code (added an include in IDE).. This results in an error:

Description Resource Path Location Type
#148 declaration is incompatible with "Uint16 RamfuncsLoadStart" (declared at line 86 of "C:/ti/controlSUITE/device_support/f2802x/v210/f2802x_common/include/F2802x_GlobalPrototypes.h") proj_lab05a.c /proj_lab05a line 97 C/C++ Problem

&&

#148 declaration is incompatible with "Uint16 RamfuncsRunStart" (declared at line 88 of "C:/ti/controlSUITE/device_support/f2802x/v210/f2802x_common/include/F2802x_GlobalPrototypes.h") proj_lab05a.c /proj_lab05a line 97 C/C++ Problem

Which I couldn't figure out?

How free am I with timer 2? I see that it is for 'general purpose' - is it used at all by InstaSPIN?

I am also having trouble setting up the PIE - largely because I don't want to 'mess' with the code too much.... I want to add:

    PIE_registerPieIntHandler(myPie, PIE_GroupNumber_1, PIE_SubGroupNumber_4, (intVec_t)&xint1_isr);
    PIE_registerPieIntHandler(myPie, PIE_GroupNumber_1, PIE_SubGroupNumber_5, (intVec_t)&xint2_isr);

    PIE_enableInt(myPie, PIE_GroupNumber_1, PIE_InterruptSource_XINT_1);
    PIE_enableInt(myPie, PIE_GroupNumber_1, PIE_InterruptSource_XINT_2);
    CPU_enableInt(myCpu, CPU_IntNumber_1);

but don't know where the most appropriate place would be - or how to add/handle the required handle? 

**Are the handles already setup or do i add my own in proj_lab05a?- handle arrays? (eg. timer[2]) are confusing me in drv. 

I also need to add the following, again I am not sure where the best place would be? -I have added it to GPIO12 in DRV ATM but as I am confused about the handles I'm not sure about it?

    GPIO_setMode(myGpio, GPIO_Number_12, GPIO_0_Mode_GeneralPurpose);
        GPIO_setDirection(myGpio, GPIO_Number_12, GPIO_Direction_Input);
        GPIO_setQualification(myGpio, GPIO_Number_12, GPIO_Qual_Sample_6);//GPIO_Qual_Sync);

          GPIO_setExtInt(myGpio, GPIO_Number_12, CPU_ExtIntNumber_1);
          GPIO_setExtInt(myGpio, GPIO_Number_12, CPU_ExtIntNumber_2);

          PIE_setExtIntPolarity(myPie, CPU_ExtIntNumber_1, PIE_ExtIntPolarity_RisingEdge);
          PIE_setExtIntPolarity(myPie, CPU_ExtIntNumber_2, PIE_ExtIntPolarity_FallingEdge);

          PIE_enableExtInt(myPie, CPU_ExtIntNumber_1);
          PIE_enableExtInt(myPie, CPU_ExtIntNumber_2);

In DRV.c I have:

 // PWM Capture, interrupt on rising and falling edges.
  GPIO_setMode(obj->gpioHandle,GPIO_Number_12,GPIO_12_Mode_GeneralPurpose);
  GPIO_setLow(obj->gpioHandle,GPIO_Number_12);//PF
  GPIO_setDirection(obj->gpioHandle,GPIO_Number_12,GPIO_Direction_Input);//PF
  GPIO_setQualification(obj->gpioHandle, GPIO_Number_12, GPIO_Qual_Sample_6);//PF

  //setup INT - shouldn't be here??
  GPIO_setExtInt(obj->gpioHandle, GPIO_Number_12, CPU_ExtIntNumber_1);
  GPIO_setExtInt(obj->gpioHandle, GPIO_Number_12, CPU_ExtIntNumber_2);

Finally, I have the ISRs in proj_lab05a.c:

interrupt void xint1_isr(void)
{
	Xint1Count++;


	CpuTimer2Regs.TCR.bit.TRB = 1; //Reload Timer
	CpuTimer2Regs.TCR.bit.TSS = 0; //Start Timer

    // Acknowledge this interrupt to get more from group 1
    PIE_clearInt(myPie, PIE_GroupNumber_1);
}

interrupt void xint2_isr(void)
{	Xint2Count++;

CpuTimer2Regs.TCR.bit.TSS = 1; //Stop Timer
test = (0xFFFFFF-CpuTimer2Regs.TIM.all)*0.00002; // Read TimerTIMER_getCount(myTimer2);

    // Acknowledge this interrupt to get more from group 1
    PIE_clearInt(myPie, PIE_GroupNumber_1);
}

As I'm sure you've guessed, the compiler is not at all happy with this..., I think most (if not, all) the errors are as a result of my confusion over handles in InstaSPIN projects and my inclusion of DSP28x_Project.h (I'd also be interested in some advice on the 'cleanest' way to add the code?)...

Chris, perfectly understandable if you don't have the time for in depth answers on all of this... very appreciative of any advice you can give me on the problems mentioned.

Patrick,

Regarding your PWM frequency, more relevant to the control is

- what is the CTRL and EST frequencies as you change the PWM frequency. I'm worried you aren't setting these up to the best of your benefit.  Use up to 3 of the PWM_TICKS first, then use the ISR_TICKS....you have to be careful that your interrupt isn't overflowing, it will cause you to use ADC results that aren't aligned with the current control loop.

- recall that you need to keep your main CURRENT_TICK to at least 7x the maximum Hz of your motor.  That is going to set your current controller rate.

- in most motors you can run FAST at a much lower rate (2.5 - 5 KHz) to save on MIPS. With the 27F running from Flash, you will need to try this.

The BOOSTXL-DRV8301 are in stock and more are being built. We don't plan to run out again!

With low flux machines (typical for these hobby motors) field weakening is essentially impossible. You will notice that you probably aren't even hitting the speed limit based on Flux / Bemf.  Your EFLITE 420 has a flux of about 0.0034 V/Hz. With an 11V bus that would suggest you can go 3200 Hz before the Bemf is the limitation...this is not the case.

Field Weakening only works on larger flux motors where the Bemf becombes larger than the bus voltage.

We will have a write-up on Lab9 in MW _13, but I've posted the how-to on here several times.  For manual field weakening it's as simple as adding negative Id_Ref_A (up to the limit in user.h).

Thanks Chris, a day glued to CCS and i'm not so confused but still can't read the PWM from my RC receiver... 

I am currently trying to count the rising and falling edges seen by GPIO12 (No timers/ticks yet)... For this I have enlisted the help of EXT. int. 1 (int1.4) and EXT. int. 2 (int1.5) of group 1. *Should I be concerning myself with interrupt priorities (are int priorities even user configurable)? 

The code (starting from a 'fresh' lab5a and drv.c/.h) (Much more succinct and readable)

In DRV.C I have added:

Setup PIE for extint 1 and 2 and enable CPU int 1

void DRV_enableRCInts(DRV_Handle handle) //PF
{
  DRV_Obj *obj = (DRV_Obj *)handle;

  PIE_setExtIntPolarity(obj->pieHandle, CPU_ExtIntNumber_1, PIE_ExtIntPolarity_RisingEdge);
  PIE_setExtIntPolarity(obj->pieHandle, CPU_ExtIntNumber_2, PIE_ExtIntPolarity_FallingEdge);

  PIE_enableExtInt(obj->pieHandle, CPU_ExtIntNumber_1);
  PIE_enableExtInt(obj->pieHandle, CPU_ExtIntNumber_2);

  CPU_enableInt(obj->cpuHandle, CPU_IntNumber_1);

}

Setup GPIO12 for reading PWM.

  // No Connection
  GPIO_setMode(obj->gpioHandle,GPIO_Number_12,GPIO_12_Mode_GeneralPurpose);
  ///////////////////////////////////////PF/////////////////////////////////////////////////
  GPIO_setDirection(obj->gpioHandle, GPIO_Number_1, GPIO_Direction_Input);
  GPIO_setQualification(obj->gpioHandle, GPIO_Number_1, GPIO_Qual_Sample_6);//GPIO_Qual_Sync);

  GPIO_setExtInt(obj->gpioHandle, GPIO_Number_12, CPU_ExtIntNumber_1);
  GPIO_setExtInt(obj->gpioHandle, GPIO_Number_12, CPU_ExtIntNumber_2);
  ///////////////////////////////////////////////////////////////////////////////////////

And in DRV.h I have added

Setup ISR

// **************************************************************************
// the globals

extern interrupt void mainISR(void);
extern interrupt void xint1_isr(void);//PF
extern interrupt void xint2_isr(void);//PF

// **************************************************************************

acknowledge external interrupt

static inline void DRV_acqRCInt(DRV_Handle handle) //PF
{
  DRV_Obj *obj = (DRV_Obj *)handle;


  // Acknowledge interrupt from PIE group 2
  PIE_clearInt(obj->pieHandle,PIE_GroupNumber_1);

  return;
}

In lab05a.c:

Variables for counting the interrupts

// the globals

volatile uint32_t Xint1Count;//PF
volatile uint32_t Xint2Count;//PF

uint_least16_t gCounter_updateGlobals = 0;

bool Flag_Latch_softwareUpdate = true;

Call initialize routines

  // setup faults
  DRV_setupFaults(drvHandle);


  // initialize the interrupt vector table
  DRV_initIntVectorTable(drvHandle);

  //PF
  DRV_initRCIntVectorTable(drvHandle);

  // enable the ADC interrupts
  DRV_enableAdcInts(drvHandle);


  // PF
   DRV_enableRCInts(drvHandle);

  // enable global interrupts
  DRV_enableGlobalInts(drvHandle);


  // enable debug interrupts
  DRV_enableDebugInt(drvHandle);

The ISRs

interrupt void xint1_isr(void)
{
	Xint1Count++;


	//CpuTimer2Regs.TCR.bit.TRB = 1; //Reload Timer
	//CpuTimer2Regs.TCR.bit.TSS = 0; //Start Timer

    // Acknowledge this interrupt to get more from group 1
   // PIE_clearInt(myPie, PIE_GroupNumber_1);
	DRV_acqRCInt(drvHandle);
}

interrupt void xint2_isr(void)
{//	Xint2Count++;

//CpuTimer2Regs.TCR.bit.TSS = 1; //Stop Timer
//test = (0xFFFFFF-CpuTimer2Regs.TIM.all)*0.00002; // Read TimerTIMER_getCount(myTimer2);

    // Acknowledge this interrupt to get more from group 1
   // PIE_clearInt(myPie, PIE_GroupNumber_1);
DRV_acqRCInt(drvHandle);
}

*************************************************No More*********************************************************

I *think this is triggering the interrupts... I say this because sending GPIO12 high or low results in the code pulling out and going into  ILLEGAL_ISR. I should also note that if I leave GPIO12 floating, everything works as it should in terms of where I am currently at with spinning motors... 

I did some research on this and I *think this may be due to the stack size setting? I tried to increase the stack from 0x200 (default) to 0x280 (the largest I could go without rewriting the linker) but it made no difference... Should I be trying to increase it further (concerned I might be off on a tangent since I barely added anything) - If so, where would you relocate .stack to? Stack size of 0x400 encroaches on .ebss in RAMM0_M1.

-Assuming you can spot something(s) that is causing trouble with my xint1/2 counts that I can fix tomorrow, the next step is counting the PWM high time. - I also want to ensure there is >15ms between falling and rising edges of the signal...

ChrisClearman said:

what is the CTRL and EST frequencies as you change the PWM frequency. I'm worried you aren't setting these up to the best of your benefit.  Use up to 3 of the PWM_TICKS first, then use the ISR_TICKS....you have to be careful that your interrupt isn't overflowing, it will cause you to use ADC results that aren't aligned with the current control loop.

I'm a bit confused about this, are you suggesting that in lieu of using a dedicated timer2,  I use a counter driving the ePWMs? How would I do this (if that is even what you meant?). USER_NUM_PWM_TICKS_PER_ISR_TICK        (3) presumably means that PWM 'clock' is running at thrice the system clock? I can do the math time my PWM signal easily enough, but where is this count stored, how do I access it?   Or am I way off course? 

- I need 1200k ticks at 60MHz to be able to verify the 15ms between falling and rising edges. This is why i thought I would need a dedicated 32bit timer (someone suggested using the Xint up counter but that would overflow being 16bit)... 

Thoughts much appreciated -as always!

What I am actually doing project wise ****** Not important, feel free to ignore ******* Thought some context might help you understand my late night posts...

Re field weakening - Ok, the motor will not reach anywhere near 3200Hz loaded so field weakening is out the window. This (FF line) is where I got the idea for this project and i'm pretty sure field weakening was used on these in an RC car (with non-negligible results and with similar sized BLDCs as mine) but I can't find it on his blog anymore so don't have any real details on how the motor was setup. In any case I'm sure you'll find the musings of another motor control genius interesting if you haven't come across it yet (Custom Observers!).

- I have about 9 weeks total left for this project.... Right now I am just trying to get the motor to spin on custom hardware. -If it spins I can get my engineering ticket regardless of efficiency/response time/precision.... Priority 1.

-The 'must haves': controllable from 50Hz RC PWM - Call identification routine by holding GPIO12 low at start-up, write identified parameters to flash and board should be comparable to commercial ESCs.

-My intention is to have the 'must have' list ticked off in the next 2-3 weeks and spend the rest of the time optimizing the ESC... I think I can improve things from default significantly just with what I've learnt talking with you and playing with the 69M EVM over the last few months.

I'm not the one to help you with the details of the rest of the code...I'm not a software expert by any means.  I'd suggest posting to the C2000 main forum and I can tag it for one of the SW pros. One thing that I noticed (that could be completely wrong), but is this supposed to be enabling the EXT interrupt?

CPU_enableInt(obj->cpuHandle, CPU_IntNumber_1);

Regarding the TICKS, you should take a look at SPRUHJ1 chapter 9 for the clock tree.
My comment is that you should understand how this works, and make sure (using the functions available) that you have interrupt headroom remaining.  It is always best if you can avoid using higher ticks for

USER_NUM_ISR_TICKS_PER_CTRL_TICK (1)

as this is a software timer for the ADC RESULTS.  Keeping actual ADC RESULTS aligned to the controller cycle that requires them is critical. I especialy don't use it during Motor ID where the timing is critical.  I haven't used it enough in a run-time control to know for sure if it works perfectly or not...I just avoid it when I can. But once you go over 45 KHz PWM rate you are probably going to have to, especially with 60 MHz F28027F.

So my comment for these high PWM Frequency, high current loop frequency control systems you are designing:

1. After setting your rather high PWM frequency, use the PWM HW decimation first. This only triggerst the ADC SOC every X event, decimating the rate of ADC RESULTS to PWM / X 

USER_NUM_PWM_TICKS_PER_ISR_TICK () // up to 3; I wish our ePWM peripheral had up to 5, that would help simplify things

2. You will need an effective CTRL rate (current/FOC) of at least 7 x Max Frequency, and 10x is better.  This will likely put you in the 15-20 KHz current controller rate.

3. When using a 60 MHz F28027F you won't have time to also run the estimator (which takes about the same amount of cycles as the current controller) at the same rate, so you will need to decimate to at least half of the current controller rate, and possibly more.

I know of Shane. Smart guy.  Even mentions InstaSPIN-FOC, but for a guy like him he's more interested in building his own mousetrap, he's not as interested in using our amazing rat catcher :)

ChrisClearman said:

I know of Shane. Smart guy.  Even mentions InstaSPIN-FOC, but for a guy like him he's more interested in building his own mousetrap, he's not as interested in using our amazing rat catcher :)

Ha! 

Chris, would be awesome if you could point an InstaSPIN software experts here for me.

Thanks - 

(I'll let you know how the rest of your suggestions go, have been stuck on damn interrupt counting all day/)

Hey Chris,

My shunt resistor PCB showed up from SparkFun today and proved that I have a fundamental misunderstanding of the quadrature current setpoint, gMotorVars.IqRef_A, ... As I understood it, this was the quadrature current control loop setpoint (obviously it is in a fashion) in amps... Meaning that my DC bus current would be the sqrt of the sum of the squares of Iq and Id... Since Id is clamped to zero, IgMotorVars.IqRef_A should be roughly equal to the DC bus current (the difference would be a measure of efficiency?). This is not the case though, for gMotorVars.IqRef_A =8, the actual bus current is only drawing 1.57A. This explains how I was able to run stock DRV8301Boost at gMotorVars.IqRef_A =15 for several minutes without setting fire to the shunt resistor. It also means that I have not gone close to putting the rated current through my motor... So, what is gMotorVars.IqRef_A? 

EDIT: something noteworthy, this is true on booth my 69M EVM and DRV8301BOOST.

From Labs documentation (Yes, I always do some research before running to you for help :-O)

"Inside of the forever loop, the Iq reference is converted from a user input of amps (gMotorVars.IqRef_A) to per unit with the following code."

At the risk of rambling, I had a thought that my initial understanding may be correct but their is a misalignment at some point (maybe per-unitising, or in the ADC range setting?)> Meaning that the motor would still run nicely but what the controller thinks is 8A is actually no where near it?? 

I checked at Iq = 1, 5,8 and 10 and in every case the bus current was wildly overestimated by the controller (or Iq is not what I think it is).. Haven't graphed it yet because there is noise on my ADC line so I have to do it manually (take voltage reading with DMM)... I am confident that my readings are correct (checked on known load)...

EDIT again: when I say Iq, I mean the setpoint gMotorVars.IqRef_A and not the Iq feedback which I should have checked and will tomorrow (I assumed it's very close to the setpoint).

////

Since I still can't figure out external interrupts using motorware APIs, I started to look into other comms... slim pickings. As I understand it, I2C is not ready for prime time on the F28027F (motorware APIs at least), SCI requires me to cut (&probably try and reroute traces) and there is no CAN peripheral on the F28027... 0->3V3 analogue could be workable but it's a very crappy solution from where I'm standing (want to demonstrate on PX4 quad, supports I2C,SCI, CAN && 50Hz PWM)... 

**What comms have you seen successfully implemented on the F28027F with instaSPIN? (not including JTAG)

Can you point me in the direction of some examples - I searched pretty thoroughly on e2e, maybe ti has something in house? If not, can I suggest comms examples with the next update of motorware, searching e2e, a few people are looking for I2C with F28027F DRV8301BOOST...

*Also, were you able to find someone to have a look at my code.. Should be patient I know, but I really want to get it working and I've been spoiled by you replying in a few hours...

Thanks again.

gMotorVars.IqRef_A is an Iq COMMAND when running in Torque mode only (speed loop disabled).   This COMMAND is also a maximum.  The motor will use only the Iq it requires / can. If you are unloaded the motor will use very little Iq.  You can't MAKE the motor use Iq...it will only use if if it is doing work (producing more torque).  That is the whole point of FOC.  You can set IqRef_A of 14A with a DRV8301 board, but if the motor does not / can not use 14A it isn't going to do so.  "You're welcome", says FOC.  Load your motor to it's limit and it will use the current it requires.  You will supply the Iq current as required up to the IqRef_A (torque  mode) or USER_MOTOR_MAX_CURRENT (speed mode)

"Meaning that my DC bus current would be the sqrt of the sum of the squares of Iq and Id."

Yes, of the Iq and Id FEEDBACK. Not the COMMAND.

"**What comms have you seen successfully implemented on the F28027F with instaSPIN?"

UART, ADC for POT, and GPIO for sure.  Agree, the driver package for non-control loop functions is not acceptable. I have highlighted this for MW _13 to be a priority.

*Also, were you able to find someone to have a look at my code.. Should be patient I know, but I really want to get it working and I've been spoiled by you replying in a few hours..."

I assigned this to someone.

Cheers Chris,

ChrisClearman said:

gMotorVars.IqRef_A is an Iq COMMAND when running in Torque mode only (speed loop disabled).   This COMMAND is also a maximum.  The motor will use only the Iq it requires / can. If you are unloaded the motor will use very little Iq.  You can't MAKE the motor use Iq...it will only use if if it is doing work (producing more torque).  That is the whole point of FOC.  You can set IqRef_A of 14A with a DRV8301 board, but if the motor does not / can not use 14A it isn't going to do so.  "You're welcome", says FOC.  Load your motor to it's limit and it will use the current it requires.  You will supply the Iq current as required up to the IqRef_A (torque  mode) or USER_MOTOR_MAX_CURRENT (speed mode)

The only thing still concerning me is the fact that I am running my motor loaded (prop) and using Iq as an effective speed controller... Doesn't this mean that the command maximum is being hit? I grabbed some data, attached (simple), but unfortunately it is not out of my code where Iq is updated (I'll get this to you tomorrow)..

Something to note is that this is my 69M running the motor that was never identified - also note the speed decreasing but the current still climbing? 

Thanks

Iq	speed (kRPM)	mV	Current A(mV/73.2mV)
1	1.41		.02	0.27uA (prop does 1Hz oscilation - current is not accurate i doubt)
2	2.07		8.7	0.118	
5	3.00		48.27	0.659
6	3.36		72	0.984
8	3.89		118	1.61
10	4.35		180.7	2.47
12	4.78		252	3.4426
14	5.18		335	4.58
16	5.5		428	4.85
18	5.3		500	6.83		(speed unstable)
20	5.0		625	8.54		(Speed decreasing)

use proj_lab09 or 10 to see the Is, Iq, Id

  // read Id and Iq vectors in amps
  gMotorVars.Id_A = _IQmpy(CTRL_getId_in_pu(ctrlHandle), _IQ(USER_IQ_FULL_SCALE_CURRENT_A));
  gMotorVars.Iq_A = _IQmpy(CTRL_getIq_in_pu(ctrlHandle), _IQ(USER_IQ_FULL_SCALE_CURRENT_A));

  // calculate vector Is in amps
  gMotorVars.Is_A = _IQsqrt(_IQmpy(gMotorVars.Id_A, gMotorVars.Id_A) + _IQmpy(gMotorVars.Iq_A, gMotorVars.Iq_A));