XMC4700: BLDC Motor Control Issue Help Needed

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User16945
Level 1
Level 1
I'm implementing a controller for a BLDC motor that uses a Hall position sensor. I've implemented this on an XMC4700 and am using the POSIF (in Hall sensor mode and Multi-Channel mode) and a few CCU4 and CCU8 slices.

I'm using one CCU4 slice to measure the rotation speed of the motor. It's configured as a counter clocked by the system clock and the capture event is the Correct Hall Event (CHE) output from the POSIF. I'm reading the capture registers in the CHE interrupt handler and using that to calculate motor RPM. I have the CCU4 slice's prescaler set to divide by 32, which puts the captured counts well within the 0-0xffff range of the counter.

Everything is working, except the motor speed as calculated from the timer capture counts is very erratic at +/- 500 RPM. When I use an accurate external tachometer instrument to read the motor RPM (set to 7000) directly at the shaft, I'm getting readings that are +/- 10 RPM. I do see some jitter on the Hall outputs from the motor on an oscilloscope, but nowhere near enough to account for the +/- 500 RPM speeds I'm calculating from the timer.

Anyone have any suggestions? What should I look at next?
0 Likes
5 Replies
Mike1
Employee
Employee
5 sign-ins First question asked 10 replies posted
Hi Soda Ant,

The possible issues could be:
- Hall Jitter
- CHE Timing -- Could be off if the expected hall pattern is not the same as the actual hall pattern
- Computation of the speed

To investigate this I recommend you make some RAM buffers and store the commutation times (capture time from the CCU4) and the calculated speed. For example you could store 100 captures and speeds in a circular buffer. Then you can compare the capture values and calculated speed with the hall times that you see on a oscilloscope.

Best regard,
Mike
0 Likes
User16945
Level 1
Level 1
Mike wrote:

The possible issues could be:
- Hall Jitter
- CHE Timing -- Could be off if the expected hall pattern is not the same as the actual hall pattern
- Computation of the speed


Thanks for the reply, Mike.

I don't think it's Hall jitter, because the magnitude of the jitter I see on an oscilloscope is not nearly enough to account for the large variance in calculated speed versus the speed measured with a tach.

It can't be a mismatch between the expected Hall pattern versus the actual pattern because I'm not seeing any Wrong Hall Events.

Computation of the speed is straightforward from the Hall timings and the results agree with the speed from the external tach (after averaging out the wide variance, of course).

I have implemented a circular buffer for the CCU4 captured counts, and they do vary widely. This is the puzzling part--why do they vary so much for a motor spinning at constant RPM with no load? I'm triggering the capture of the CCU4 counter via the CHE from the Posif, and have the CCU4 set to clear on every capture event. I'm not getting capture overruns (because I'm only seeing valid capture data in C1V and never in C0V.
0 Likes
User16945
Level 1
Level 1
Okay, here's the answer... Mike had it right: it's a Hall glitch issue. It doesn't happen on every Hall transition, but it happens enough to throw off the RPM measurements. I was unlucky enough not to capture it on the scope the first time I looked.

Here's a scope shot showing the smoking gun. Channel 4 (purple trace) is one of the Hall inputs from the motor. The glitch is obvious.

3707.attach
0 Likes
User15886
Level 1
Level 1
Soda Ant - thanks for updating the thread with what you found. We are looking at using the POSIF on our BLDC motor controller and it will be helpful if we see the same issue.
0 Likes
Mike1
Employee
Employee
5 sign-ins First question asked 10 replies posted
Wow. That is a lot of glitches on the hall signal. The POSIF has a digital filter on the inputs, but it can only filter out noise of up to 64 clocks (see bit register PCONF.LPF). For glitches as long as the ones in your screen shot you can use the POSIF.OUT0 signal to trigger a CCU4 slice to de-bounce the hall edges. The CCU4 slice ST signal can be fed back into the POSIF HSD input so that the POSIF will re-sample the Hall signals when the HSD input becomes active. Then the POSIF will only process the Hall signals if the sampled signal has been stable for the amount of time controlled by the CCU4 slice. For your system it looks like you would need a delay of 500usec which seems quite high.
0 Likes