BLDC High side current measurment w.r.t PWM control on 3.6

Status
Not open for further replies.

RRdae

Active member
I am constructing a controller/driver to do position and current control of a hobby grade brushless DC motor. I have everything prototyped and assembled, but I am having some issues reliably measuring current using the onboard current sense resistor and amplifier.

Current is measured on the supply side of the mosfet drive section via an 0.001ohm resistor, which is amplified by a MAX40201FAUA amplifier (gain of 50). No hardware filtration was implemented (I seriously regret not at least adding provisions to the pcb to add this). The three motor phases are controlled via pwm on pins 21, 22, 23 on a Teensy 3.6 @ 40khz. Output is sinusoidal.

The issue that I am having is that when I am trying to calibrate for cogging current at low power (pwm differential duty cycle <= 10%) I essentially need to read the voltage drop across the resistor, via the ADC on pin 16, during a very precise window of the PWM waveform (when at least one high side and one low side mosfet is turned on, separate phases of course). This means that I either need to sample at a very high rate (~4Msps) or somehow synchronize the current sense analogread to the PWM output so that it queries in the middle of the PWM waveform (where the difference in PWM output on the three phases actually cause a voltage differential across the motor), correct?

Can anyone offer any advice on this? Random sampling of the current sense voltage is giving very sporadic readings, as it samples both when the mosfets are active and inactive.

Thanks!


To clarify what I mean by differential PWM, picture two PWM waveforms controlled by a sinusoidal function. They perfectly overlap, so the mosfets they control are both either on or off at the same time, no power flows. Now if a small increment is introduced in one sinusoidal function, the waveforms stay sychronized, but they no longer overlap. This small delta introduces a differential that causes the mosfets they drive to be on or off at slightly different times. I hope it doesn't sound like I am lecturing, I just do not know the proper terminology for this.
 
1.) I think NXP has some app note regarding control of motors and monitoring their current. The reference is on my work PC though.
2.) I think the fellow that wrote the analog stuff, (Mr) Pedvide (?), also made provisions in there to control when the analog sampling takes place, controlled by the FTM or PDB. It can be found on github.
3.) I wish I could help you out more, but hopefully I've given some info to lead you in the right direction.
Stay healthy.
 
Thank you. I spent most of yesterday browsing NXP and with the help of some better keywords for searching, I found a similar thread on the forum from a few years back. The main difference there is that they were using CPWM and triggering the ADC at the start position of the PWM waveform, where as I am locked to EPWM and need to trigger the ADC at the centerpoint of the PWM waveform (When FTM0_CNT == 1/2 of FTM0_MOD, If I understand those correctly).

This will be my first foray into the inner workings of the teensy 3.6 and an interesting pain in the rear to learn.
 
I'm sure that there are complexities that I don't appreciate--- and I have a question about the OP's description:

To clarify what I mean by differential PWM, picture two PWM waveforms controlled by a sinusoidal function. They perfectly overlap, so the mosfets they control are both either on or off at the same time, no power flows. Now if a small increment is introduced in one sinusoidal function, the waveforms stay sychronized, but they no longer overlap. This small delta introduces a differential that causes the mosfets they drive to be on or off at slightly different times.

The part about no current flowing when both signals are the same leads me to think that one PWM goes to an N-channel MOSFET and the other to a P-channel FET. Is this correct, or is there some driver circuit between the PWM and the MOSFETS?
What do you mean by "a small increment is introduced" ? Does that mean that one PWM has a different duty cycle response to the input sine value? Or does it mean that the two channels have the same response to the input sine wave, but one sine wave is shifted in time (or phase) with respect to the other?

One approach you could try:
Set up a new PWM output synchronized with the motor control PWM, but with half the duty cycle of the motor control. The falling edge of that PWM signal should occur in the middle of the motor control PWM pulse. Then you could connect that output to a GPIO input pin and have it trigger an interrupt on the falling edge. During the service routine for that interrupt you could read the ADC value. I think this might be a bit simplistic. Perhaps you want your sampling to be in the middle of the interval when the two PWM outputs are different. In this case you need to do a bit of math to have the third PWM have its falling edge in the middle of the time between PWM1 falling and PWM2 falling. It seems simple for two phases, but may get more complex with three phases.
 
@grease_lighting

I looked over the ADC library, but I did have not seen any provisions to sync ADC measurements to an FTM clock. Have you used the ADC in this manner? I would greatly appreciate being pointed to the documentation that covers that. :)



The part about no current flowing when both signals are the same leads me to think that one PWM goes to an N-channel MOSFET and the other to a P-channel FET. Is this correct, or is there some driver circuit between the PWM and the MOSFETS?

An HIP4086 driver IC is used between the Teensy and the N channel MOSFETs to allow high side triggering. The HIP4086 also handles dead time insertion to avoid shoot thru. The inputs from the teensy are fused entering the HIP4086 so that only a single input is required for each phase/channel instead of two (separate HIGH side & LOW side MOSFET controls).

What do you mean by "a small increment is introduced" ? Does that mean that one PWM has a different duty cycle response to the input sine value? Or does it mean that the two channels have the same response to the input sine wave, but one sine wave is shifted in time (or phase) with respect to the other?

What I mean by that is that with my control system, a zero control output (one that is not trying to move the motor) has a PWM output of 40khz and 50% duty cycle, with all three phases/channels synchronized. The effect of this is that no power flows because all three phases have the same state at any given time. When motion is desired, the three phases deviate from the 50% centertap duty cycle (+/-) by some amount, determined by three sinusoidal waveforms which are each offset from one another by 120 degrees. The frequency of the PWM does not change and the three PWM forms are always sychronized, but changes in duty cycle simulate 3 phase locked sinusoidal forms. I center the input about the 50% duty cycle point because it avoids having very short PWM ON or OFF times (at <3% Duty or >97% duty), as the hardware dead time could cause issue with with these if the on or off pulse is shorter than the programmed hardware deadtime.


One approach you could try:
Set up a new PWM output synchronized with the motor control PWM, but with half the duty cycle of the motor control. The falling edge of that PWM signal should occur in the middle of the motor control PWM pulse. Then you could connect that output to a GPIO input pin and have it trigger an interrupt on the falling edge. During the service routine for that interrupt you could read the ADC value. I think this might be a bit simplistic. Perhaps you want your sampling to be in the middle of the interval when the two PWM outputs are different. In this case you need to do a bit of math to have the third PWM have its falling edge in the middle of the time between PWM1 falling and PWM2 falling. It seems simple for two phases, but may get more complex with three phases.

That is a great idea! Unfortunately all FTM0 pins are already hard connected to other applications. There are two which could be used in the future on the next hardware iteration, but for now they are connected to a hall effect sensor's secondary comm channel which probabily wouldnt like receiving a pwm waveform from the teensy.

I have been diving into the teensy 3.6 literature and it has interrupts on the FTM clocks that trigger at the start of the waveform (EPWM) or in the center of the waveform (CPWM). If I had a spare channel open, I would do as you suggested, setting a separate PWM output on the same FTM at twice the driver frequency (80khz), then using hardware interrupts to sample the current sense ADC at the start of that pwm waveform (centerpoint of the motor pwm waveform). Theres always something to complicate things, right? Fortunately, tho, I am only really concerned about total current consumption, not individual leg current flow, as I have onboard position sensing to handle phase alignment, so I only need to sample the current sense resistor supplying power to the whole MOSFET group.

------

More recently, I found the documentation for the Programmable Delay Block in the K66 (teensy 3.6). It sounds like exactly what I need, IF (and that may be a BIG if) it can work in a very particular way.

What I am considering is:
1. Having FTM0 trigger a hardware interrupt at the start of each PWM cycle.
2. The interrupt from (1) triggers the Programmable Delay Block (PDB).
3. The PDB delays for a time period one half that of the FTM PWM period.
4. Once done, the PDB triggers the ADC to read the current sense resistor, then resets for next cycle. ADC computation commences.
5. Once computation is complete, an interrupt is triggered and the software reads the ADC value when ready.

If I am understanding everything correct (and honestly, I am probably not), all that should be capable of running on hardware side of things and not actually impede the software until its time to read the computed ADC value. It also looks like the Teensy (K66) has the capability to do hardware averaging on the ADC, which could potentially help by moving that operation from the software side of things.
 
Last edited:
Status
Not open for further replies.
Back
Top