Teensy 4.0 PWM glitching every 4-5s, at 500Hz for high duty cycles

rjsdotorg

Well-known member
I have a small BLDC motor (5 wire with internal control board) and doing PWM control.
As per the Teensy docs:
Vales 0 and 256 are meant to correspond to logic low and high. However, the PWM hardware may not be capable of truly 100% low or high. A very short pulse may occur between each PWM cycle where the pin is driven to begin a new cycle, and then very quickly changed because the setting attempts to keep the pin always low or always high. To avoid any small glitch pulses, the pin may taken out of PWM mode using pinMode() and then controlled by digitalWrite().
Anytime you are doing PWM at high duty cycle it glitches every 4.3-5s, with exactly 500Hz. This is with or without a 4.7k pull-up.
Ie, analogWrite(2, 255); enables it - actually >=240 causes the action, while 239 is a slow roll and 256 a true stop.
analogWriteFrequency(nnnnn) does not affect it.
analogWrite(2, 0); runs smoothly.

What does teensy_slow_pwm do? Anything helpful? SoftPWM does not look helpful.
Will https://shawnhymel.com/649/learning-the-teensy-lc-manual-pwm be of use?

If anyone has suggestions - I'd like to hear, otherwise I'll work around it...

I was a little concerned about ground potential difference between the 12V wall wart and the laptop USB power, but tying them together does not seem to affect anything at all.

Code:
# Teensy BLDC Motor Controller with Speed Feedback
This project controls a BLDC motor with built-in driver using a Teensy 4.x microcontroller, providing PWM speed control, direction control, and speed feedback monitoring.
## Hardware Connection Diagram
```
┌─────────────────────────────────────┐
│         Teensy 4.x                  │
│                                     │
│  Pin 2 (PWM) ──────────────────┐    │
│                                │    │
│  Pin 3 (DIR) ──────────────────┼──┐ │
│                                │  │ │
│  Pin 4 (Frequency)  ───────────┼──┼─┼──┐
│                                │  │ │  │
│  (Common Ground) ──────────────┼──┼─┼──┼──┐
│                                │  │ │  │  │
│                                │  │ │  │  │
└────────────────────────────────┼──┼─┘  │  │
                                 │  │    │  │
                                 │  │    │  │
                ┌────────────────┼──┼────┼──┼────────────┐
                │    BLDC Motor  │  │    │  │ Controller │
                │ WHITE wire  ◄──┘  │    │  │  (PWM)     │
                │ GRN  wire   ◄─────┘    │  │  (DIR)     │
                │ YELLOW wire ◄──────────┘  │  (FG)      │
                │ BLACK wire  ◄──┼──────────┘  (PWR GND) │
                │                │                       │
                │  RED wire ◄──┐ │(Motor Power +12V)     │
                └──────────────┼─┼───────────────────────┘
                               │ │
        ┌────────────────────┐ │ │
        │   12V Power Supply │ │ │
        │                    │ │ │
        │  +12V ─────────────┼─┘ │
        │  GND ──────────────┼───┘ (Common Ground)
        └────────────────────┘
```
## Connection Summary
| TEENSY Pin | BLDC Motor Wire | Function |
|------------|----------------|----------|
| Pin 2 | WHITE wire | PWM Speed Control (0-5V) |
| Pin 3 | BLUE wire | Direction (Float/GND) |
| Pin 4 | YELLOW wire | FG Feedback (speed sensor) |
| GND | BLACK wire (logic) | Common Ground |
| - | RED wire | Motor Power (+12V) |
| - | BLACK wire (power) | Motor Power Ground |
## Important Notes
- Ensure common ground between Teensy and 12V power supply
- **PWM wire (WHITE)**: 0-5V PWM signal controls motor speed
- **Direction wire (BLUE)**: Float = one direction, GND = opposite direction
- **FG wire (YELLOW)**: Outputs speed feedback pulses for RPM monitoring
- **Motor power (RED/BLACK)**: Separate high-current power lines for the motor
## Usage
1. Upload the code to your Teensy 4.x
2. Open Serial Monitor at 9600 baud
3. When prompted, enter a 3-digit PWM value (0-255) to set motor speed
4. Motor will run in one direction, then reverse
## Features
- PWM speed control with 10kHz frequency
- Bidirectional motor control
- Real-time speed feedback monitoring via FG pin
- Frequency-to-duty cycle mapping for closed-loop control
- Serial interface for speed input and monitoring
## Hardware
- **Motor**: B2418 Mini 310 BLDC Brushless Motor with built-in driver
- **Microcontroller**: Teensy 4.x
- **Power Supply**: 12V DC
 

Attachments

  • main.cpp
    4.1 KB · Views: 64
Last edited:
As an update, I'm thinking that the behavior is mostly in the controller of the BLDC (can't update first post now).
"specs" say "PWM signal speed regulation around 10-20kHz" but actually runs from hundreds up to 100kHz.
"signal feedback requires pull-up resistor." which sounds like open-drain but not verified - I have INPUT_PULLUP. It likely needs a filter cap otherwise the feedback interrupt pin fires with noise at no-rpm giving erroneous readings.

MAINLY
"The speed regulation range under 12V voltage is approximately 300-5000 revolutions per minute." is what leads me to think low cogging/jumping is a known fundamental design issue.
Speed is still proportional to V, and lower Vin requires higher minimum duty %. I was encouraged that it works down to 3V, with proportionately less speed and torque (no load):
Vinslow pwm duty
(of 256)
RPMfull speed pwm dutyRPM
1223517604580
923510803580
4.52278001985
32177701488
IMG_9156.JPG


Direct control of the windings is not possible without hacking the circuit board, which obviates the point of simple PWM control
Clipboard01.jpg

It might still be interesting to try manual Teensy PWM but maybe later.
 
In conclusion, after much wrangling - it is a baked-in startup behavior of the driver chip, as programmed by the vendor.
I bought a 2408 kit and will try that next.


The B2418’s built-in FT8213Q is a sensorless FOC controller. At zero and very low speed, it cannot derive rotor position from back-EMF, so it must execute its internally programmed startup sequence—initial-position detection, alignment and open-loop acceleration—before it can transition to closed-loop operation. The startup parameters, minimum output, control mode and protection behavior are stored in the chip’s EFUSE and are therefore fixed by the motor-board manufacturer.

Why your PWM ramp does not remove the jerk

The speed input does not directly command phase current or rotor acceleration. It commands an internal output target. The FT8213Q speed-control curve includes a configurable minimum output, OutMin, once the input crosses the enable threshold, pwm_off. That creates an inherent discontinuity between stopped and running states.

Therefore:
  1. Below the startup threshold, the motor is stopped.
  2. Crossing the threshold invokes the chip’s internally programmed startup routine.
  3. The chip applies enough phase excitation to locate and accelerate the rotor.
  4. Only after acquiring adequate rotor-state information does normal sensorless closed-loop control begin.
  5. If the requested operating point is below the motor/controller’s sustainable sensorless speed, it stalls.
  6. Motor-lock protection then initiates another restart attempt, producing periodic kicks.
Your observation that different PWM ramps produce substantially the same initial burst is exactly what would be expected. The external controller cannot modulate the FT8213Q’s internal phase-current trajectory during startup.

Practical conclusion​

The B2418 is not suitable for a genuinely smooth 0 → 50 RPM start, even though it may run near 50–100 RPM after being manually or electrically brought up to speed.

It may still satisfy:
  • 50–1500 RPM after startup
  • low cost
  • compact dimensions
  • built-in driver
  • FG speed feedback
But it does not satisfy:
  • smooth start from rest
  • controlled acceleration through the first revolution
  • deterministic low-speed torque
  • zero-jerk restart after a stall
Changing PWM frequency, adding a longer ramp, briefly lowering the supply voltage or using FG feedback around the speed command will not fundamentally correct the first commutation event. Supply-voltage reduction might reduce its magnitude, but can also make startup less reliable and provoke repeated restart attempts.
 
Back
Top