1.Tổng quan hệ thống

Dự án DieuKhienBLDC điều khiển một động cơ BLDC 3 pha để vận hành một cánh cửa tự động (mở/đóng theo 2 chiều THUẬN - NGHỊCH). Bộ điều khiển dùng vi điều khiển STM32F103C8, mã nguồn sinh bởi STM32CubeMX (lớp HAL) và được bổ sung thêm một lớp thư viện riêng (BSP / Motor / Debug) trong thư mục MyLibrary để xử lý các chức năng đặc thù của BLDC.

Hệ thống gồm 4 khối chức năng chính:

• Công suất: driver 3 pha SLM2009 điều khiển 6 MOSFET (3 High-side qua PWM, 3 Low-side qua GPIO ON/OFF).
• Phản hồi vị trí/tốc độ: 3 cảm biến Hall đọc bằng polling mỗi vòng lặp, kết hợp bộ đếm step để suy ra vị trí và tốc độ quay.
• Đo dòng điện: ADC1 quét vòng 9 kênh qua DMA, trong đó 2 kênh dùng để giám sát dòng pha B/C (phát hiện kẹt cơ khí / vật cản), 6 kênh còn lại đọc 6 biến trở trên panel điều khiển vật lý.
• Giao tiếp/điều khiển: UART3 115200bps dùng chung cho 2 mục đích - xuất log debug (Hall, dòng điện, đỉnh dòng) và nhận khung lệnh nhị phân mở/đóng cửa từ xa.

2.Kiến trúc phần cứng - ánh xạ chân

2.1. Khối công suất (High-side PWM qua TIM1)

2.2. Cảm biến Hall

Cả 3 chân đọc trong CÙNG một lần đọc thanh ghi GPIOB->IDR để tránh "xé" (tearing) giữa các bit khi Hall đổi rất nhanh - xem mục 5.

2.3. Kênh ADC (ADC1, quét vòng qua DMA, 9 kênh)

2.4. Nút bấm / cảm biến / báo lỗi

PA15 và PB3 mặc định thuộc chức năng JTAG - BSP_GPIO_Init() chủ động gỡ bỏ (remap SWJ-NOJTAG) để giải phóng 2 chân này cho mục đích khác.

2.5. Giao tiếp

3.Kiến trúc phần mềm (các lớp module)

Mã nguồn được chia thành 3 lớp trên nền HAL do CubeMX sinh (Core/Src):

4.Vòng lặp chính (7 bước trong while(1))

Mỗi vòng lặp while(1) trong main() thực hiện tuần tự 7 bước sau:

4.1. Chú thích: luồng tín hiệu FORWARD - từ nút nhấn đến PWM

ĐIỂM BẮT ĐẦU → chân GPIO nút bấm forward (mục 2.4) được đọc và debounce 5 lần đọc liên tiếp trong BSP_GPIO_Update() (bsp_gpio.c) → hệ thống phát hiện sườn lên (rising edge) của tín hiệu đã debounce này (bước 3, mục 4) → nếu đang ở trạng thái rảnh RUN_STATE_TEST_IDLE, vòng lặp chính (bước 4, mục 4) chuyển trạng thái sang RUN_STATE_TEST_SPIN_FWD, lưu test_spin_start_position/test_spin_start_tick, áp duty "kick" khởi động ban đầu MOTOR_KICK_DUTY_PERCENT (mục 10) → mỗi vòng lặp kế tiếp, trong hàm Run_Task(hall_confirmed) (bước 5, mục 4), nhánh case RUN_STATE_TEST_SPIN_FWD gọi Motor_RampDuty_Generic() (mục 9) tính duty hiện tại theo progress (accel → run → decel) → gọi Motor_Commutation_Direction() (Hall/hướng vừa đổi) hoặc Motor_Commutation_UpdateDuty() (chỉ đổi duty) (mục 6.2), tra bảng chuyển mạch CHIỀU THUẬN (mục 6.1, dùng THẲNG mã Hall đọc được - KHÔNG còn dịch bước, xem mục 6.4) để chọn đúng cặp High-PWM / Low-ON → giá trị duty được ghi vào thanh ghi Compare (CCR) của TIM1 cho đúng kênh High-side (PA8/PA9/PA10 = WH/VH/UH, mục 8), đồng thời BSP_PWM_xx_On()/Off() điều khiển đúng chân Low-side GPIO (PB13/14/15 = WL/VL/UL) theo cực tính đảo của SLM2009 (mục 7) → ĐIỂM KẾT THÚC: xung PWM thực tế xuất hiện trên chân High-side tương ứng, điều chế bởi TIM1 - đây là tín hiệu điều khiển trực tiếp đưa vào driver công suất SLM2009 để quay động cơ.

4.2. Sơ đồ giải thuật tổng quan (vòng lặp chính + máy trạng thái)

Sơ đồ thể hiện nhánh RUN_STATE_TEST_SPIN_FWD của Run_Task() - nhánh TEST_SPIN_REV giống hệt về cấu trúc, chỉ đổi dấu tính progress, đổi tham số direction = -1, và tra bảng chuyển mạch NGHỊCH thay vì THUẬN.

5.Đọc Hall và debounce

Hall_Read() (trong bsp_hall.c) đọc CẢ 3 bit Hall trong CÙNG một lần truy cập thanh ghi GPIOB->IDR để tránh hiện tượng "xé" (tearing) - tình huống 2 lần đọc riêng lẻ rơi vào đúng lúc một bit vừa đổi, cho ra tổ hợp Hall không từng tồn tại thực sự.

uint8_t Hall_Read(void)
{
    uint32_t idr = GPIOB->IDR;

    uint8_t u = (idr >> 4) & 1U;   /* PB4 = Hall_A -> bit0 */
    uint8_t v = idr & 1U;          /* PB0 = Hall_C -> bit1 */
    uint8_t w = (idr >> 5) & 1U;   /* PB5 = Hall_B -> bit2 */

    return (w << 2) | (v << 1) | u;
}

Giá trị thô này được đưa qua bộ lọc debounce trong vòng lặp chính (bước 1, mục 4): một giá trị Hall chỉ được chấp nhận vào hall_confirmed - biến DUY NHẤT mà toàn bộ logic điều khiển (commutation, vị trí, tốc độ, máy trạng thái, log UART) sử dụng - sau khi đọc ổn định HALL_DEBOUNCE_COUNT = 3 lần liên tiếp VÀ là một trong 6 mã hợp lệ (Hall_IsValid(): 001, 101, 100, 110, 010, 011 - loại bỏ 000 và 111 là lỗi cảm biến/dây đứt).

6.Thuật toán commutation 6 bước (6-step BLDC)

Đây là thuật toán trung tâm của toàn bộ hệ thống, cài đặt trong motor_commutation.c. BLDC 3 pha điều khiển theo phương pháp "trapezoidal 6-step": tại mỗi thời điểm chỉ 2 trong 3 pha dẫn dòng (1 pha High-side PWM, 1 pha Low-side ON cố định), pha còn lại thả nổi (dùng để cảm nhận back-EMF trong các thiết kế cảm biến-less, nhưng dự án này dùng cảm biến Hall thật nên không cần).

6.1. Thứ tự Hall và bảng chuyển mạch

Luồng CHIỀU THUẬN (chú thích): xuất phát từ Hall = 001 (điểm BẮT ĐẦU của chu kỳ) → 101 → 100 → 110 → 010 → 011 → quay VÒNG LẶP LẠI về 001 (không có điểm "kết thúc" - động cơ còn quay thuận thì chuỗi này lặp lại vô hạn). Trạng thái hiện tại (sau khi HOÀN TÁC lead-commutation, xem mục 6.4): vector PWM/Low áp dụng ĐÚNG BẰNG mã Hall vừa đọc được - KHÔNG còn dịch trước 1 bước như bản thử nghiệm trước đó.

Bảng NGHỊCH chính là bảng THUẬN với High và Low HOÁN ĐỔI cho nhau trên cùng một cặp pha - đã được đối chiếu từng dòng và xác nhận khớp 100% với comment đầu file trong lần rà soát gần nhất.

6.2. Hai hàm commutation: Direction() và UpdateDuty()

• Motor_Commutation_Direction(hall, direction) - gọi khi Hall HOẶC hướng quay THỰC SỰ thay đổi so với bước trước (active_hall/active_direction). Nếu không đổi gì, hàm thoát ngay (không làm gì). Nếu có đổi: BSP_PWM_AllOff() tắt toàn bộ 6 MOSFET -> chờ dead time -> bật lại đúng cặp MOSFET High/Low theo bảng chuyển mạch của hướng tương ứng.
• Motor_Commutation_UpdateDuty() - gọi khi CHỈ cần đổi độ rộng xung (duty), Hall/hướng không đổi. Chỉ ghi lại giá trị Compare (CCR) của kênh PWM đang active, KHÔNG tắt/đụng lại GPIO Low-side, KHÔNG dead time - đảm bảo dòng điện liên tục, không bị "bấm/nháp" (chopping) ở tần số vòng lặp.

/* Dead time hiện tại: vòng lặp NOP - KHÔNG chính xác tuyệt đối về thời gian,
   có thể bị ảnh hưởng bởi ngắt/trình biên dịch. Chỉ phù hợp cho mục đích
   test ở duty thấp; cần thay bằng DWT cycle counter hoặc timer riêng
   nếu triển khai công suất thật. */
static void Motor_DeadTime(void)
{
    volatile uint32_t i;
    for (i = 0; i < 50; i++) { __NOP(); }
}

6.3. Hãm điện (dynamic brake)

Motor_Commutation_Brake(): tắt toàn bộ PWM High-side (duty=0) và BẬT CẢ 3 Low-side cùng lúc, ngắn mạch 3 cuộn dây qua Low-side. Dòng cảm ứng sinh ra từ sức điện động ngược (rotor còn quay do quán tính) bị ngắn mạch tạo mô-men hãm ngược chiều quay, giúp dừng nhanh hơn đáng kể so với cắt điện hoàn toàn (coast). Không cần dead time ở bước này vì không có High-side nào PWM cùng lúc với Low-side đang bật.

6.4. Thử nghiệm "lead commutation" cho chiều THUẬN - ĐÃ ÁP DỤNG RỒI HOÀN TÁC

Giải pháp đã THỬ NGHIỆM là kỹ thuật "lead commutation" chuẩn cho trường hợp Hall bị lệch pha: dịch bảng THUẬN đi 1 bước qua hàm Hall_ThuanNext() (dùng vector của bước Hall KẾ TIẾP trong chuỗi thuận thay vì bước hiện tại), áp dụng trong cả Motor_Commutation_Direction() và Motor_Commutation_UpdateDuty(), chỉ cho nhánh THUẬN. Kết quả đã xác nhận qua máy phân tích logic (Saleae Logic 2): chiều THUẬN tự khởi động và chạy đúng qua nhiều chu kỳ liên tục sau khi áp dụng.

6.4.1. Bảng so sánh: đang ÁP DỤNG (raw Hall) vs THAM KHẢO (đã dịch bước, không còn dùng)

2 bảng bên phải chỉ mang tính THAM KHẢO cho tương lai (nếu cần thử nghiệm lại lead-commutation) - hiện KHÔNG có dòng code nào áp dụng chúng. Cả 2 chiều THUẬN và NGHỊCH đang dùng đúng 1 bảng duy nhất (cột trái) tra thẳng theo mã Hall đọc được, giống hệt cách NGHỊCH vẫn luôn hoạt động.

7.Driver SLM2009 và vấn đề đảo cực LIN

Driver công suất SLM2009 điều khiển các chân Low-side (LIN -> LO) theo cực tính NGƯỢC so với High-side (HIN -> HO):

void BSP_PWM_UL_On(void)
{
    HAL_GPIO_WritePin(UL_GPIO_Port, UL_Pin, GPIO_PIN_RESET);   /* LIN=0 -> LO=1 (ON) */
}

void BSP_PWM_UL_Off(void)
{
    HAL_GPIO_WritePin(UL_GPIO_Port, UL_Pin, GPIO_PIN_SET);     /* LIN=1 -> LO=0 (OFF) */
}

Cùng logic áp dụng cho VL/WL. Đây là một trong những điểm dễ gây nhầm lẫn nhất khi đọc raw log tín hiệu (logic analyzer) - cần luôn quy đổi qua bảng này trước khi kết luận một pha có đang "ON" hay không (xem thêm mục 16, hạng mục kiểm tra shoot-through).

8.Điều chế PWM và duty

3 kênh PWM High-side dùng chung TIM1 với ARR = 3199 (Period). Duty phần trăm được quy đổi sang giá trị Compare theo công thức:

compare = ((ARR + 1) * percent) / 100;   /* percent được giới hạn 0..100 trước đó */
/* ví dụ: 0% -> 0 | 50% -> ~1600 | 100% -> ~3200 (giới hạn lại tối đa 3199) */

BSP_PWM_SetDutyPercent() áp dụng CÙNG một giá trị duty cho cả 3 kênh (dùng khi cần đặt đồng loạt, ví dụ lúc hãm điện). Trong vận hành bình thường, module motor_commutation.c tự chọn ĐÚNG kênh cần PWM (U/V/W) theo bảng chuyển mạch ở mục 6, các kênh còn lại được đặt về 0 bởi BSP_PWM_AllOff() trước khi chuyển bước.

9.Ramp tốc độ hình thang (accel / run / decel)

Duty không được áp đặt ngay mức "chạy" (run) mà tăng/giảm dần theo dạng hình thang, thực hiện bởi Motor_RampDuty_Params() - hàm dùng chung cho cả chế độ test-spin lẫn chế độ production (VR).

Hàm nhận vào progress (số step đã đi kể từ lúc bắt đầu) và tính duty theo 3 vùng:

1. Vùng tăng tốc (accel): khi progress < accel_steps, duty tăng tuyến tính từ duty_accel_start lên duty_run.
2. Vùng chạy ổn định (run): khi progress nằm giữa vùng tăng tốc và điểm bắt đầu giảm tốc, giữ nguyên duty_run.
3. Vùng giảm tốc (decel): khi progress >= target_steps - decel_steps, duty giảm tuyến tính từ duty_run xuống duty_decel_min khi tiến tới target_steps.

Hàm này được tham số hóa đầy đủ (duty_accel_start, duty_run, duty_decel_min, accel_steps, decel_steps) để dùng chung cho cả:

• Chế độ test-spin hiện tại (Motor_RampDuty_Generic()): dùng hằng số cố định MOTOR_TEST_DUTY_ACCEL_START / MOTOR_TEST_DUTY_RUN / MOTOR_TEST_DUTY_DECEL_MIN và MOTOR_ACCEL_STEPS/MOTOR_DECEL_STEPS (4 vòng điện mỗi bên, 24 step/vòng).
• Chế độ production (chưa kích hoạt): dùng các giá trị lấy từ biến trở VR trên panel (prod_fwd_run_duty, prod_fwd_creep_duty, prod_fwd_decel_steps... - xem mục 14).

10.Cơ chế "kick" khởi động

Mục đích: thắng "điểm kết" cơ khí/từ lúc rotor đứng yên bằng cách ép duty CỐ ĐỊNH cao hơn duty_accel_start trong MOTOR_KICK_DURATION_MS (300ms) đầu tiên ngay sau khi nhận lệnh quay, trước khi chuyển về ramp bình thường - tương tự thao tác "mồi tay" nhưng bằng điện.

#define MOTOR_KICK_DUTY_PERCENT      MOTOR_TEST_DUTY_ACCEL_START   /* đang = accel_start -> VÔ HIỆU HÓA */
#define MOTOR_KICK_DURATION_MS       300U

11.Bảo vệ / an toàn (stall, quá dòng)

11.1. Phát hiện stall qua cảm biến dòng điện (Motor_StallDetected)

Dùng trong luồng production (calibration tìm giới hạn cơ khí, phát hiện vật cản khi đóng cửa). Đọc MAX(PA1, PA2) - dòng pha B và pha C, hai kênh đã xác nhận có đấu nối thật - so với ngưỡng MOTOR_STALL_ADC_THRESHOLD. Lý do lấy MAX cả 2 kênh: tại một thời điểm chuyển mạch, BLDC chỉ dẫn dòng qua 2/3 pha, nên phải đảm bảo không bỏ sót trường hợp kẹt đứng vào đúng bước mà pha B hoặc pha C đang là pha dẫn dòng.

#define MOTOR_STALL_ADC_THRESHOLD     2048U   /* placeholder - CẦN HIỆU CHỈNH BẰNG THỰC NGHIỆM */
#define MOTOR_STALL_DEBOUNCE_COUNT    5U      /* số lần đọc VƯỢT ngưỡng liên tiếp để xác nhận */

11.2. Watchdog thời gian cho chế độ test-spin (không đọc ADC)

Vì RUN_STATE_TEST_SPIN_FWD/REV không đọc ADC để bảo vệ (chế độ test tạm thời), cần một lớp bảo vệ riêng: nếu hall_confirmed không đổi trong MOTOR_STALL_TIMEOUT_MS kể từ lần đổi Hall gần nhất, PWM được cắt NGAY (không chờ brake) để tránh dòng cao liên tục gây sụt áp nguồn hoặc hỏng MOSFET/driver.

11.3. Tín hiệu báo quá dòng phần cứng (SSCR_U)

PB12 là tín hiệu báo quá dòng từ mạch ngoài (đọc trực tiếp, không debounce). BSP_GPIO_WasCurrentTripUHighSinceReset() chốt (latch) trạng thái này từ lần lên mức cao gần nhất, chỉ được reset chủ động qua BSP_GPIO_ResetCurrentTripULatch() (gọi mỗi lần bắt đầu một lần test-spin mới). Kết hợp với đỉnh dòng PA1/PA2 (peak-hold), giá trị này được gửi qua UART khi watchdog stall kích hoạt (dòng "PA1max=.. PA2max=.. SSCR_U=..") để phục vụ phân tích sau sự cố.

12.Đo vị trí và tốc độ động cơ

12.1. Vị trí (motor_position.c)

Vị trí được biểu diễn bằng bộ đếm step Hall tuyệt đối (int32_t motor_position): mỗi lần Hall THỰC SỰ đổi và hợp lệ, bộ đếm tăng (chiều THUẬN) hoặc giảm (chiều NGHỊCH) 1 đơn vị. Quy ước: 6 Hall step = 1 chu kỳ điện, 4 chu kỳ điện = 1 vòng cơ -> 24 Hall step = 1 vòng cơ. Đây là cơ sở để tính progress dùng cho ramp duty (mục 9) và target đích (mục 13).

12.2. Tốc độ (motor_speed.c)

Chu kỳ Hall được đo bằng TIM3 chạy ở 1MHz (1 tick = 1us): mỗi lần Hall đổi, tính khoảng cách tick so với lần trước (hall_period_us), từ đó suy ra RPM điện và RPM cơ:

RPM_dien = 60,000,000 / (period_us * 6)     // 6 step Hall / vòng điện
RPM_co   = 60,000,000 / (period_us * 24)    // 24 step Hall / vòng cơ

Chiều quay được suy ra độc lập từ CẶP Hall (trước, hiện tại) qua Motor_Speed_HallDirection(), đối chiếu với 2 bảng thứ tự THUẬN/NGHỊCH ở mục 6.1 - nếu cặp Hall không khớp bảng nào cả (nhảy 2 bước hoặc Hall lỗi), hàm trả về 0 và bỏ qua lần cập nhật đó.

Module này hiện chủ yếu cung cấp giá trị RPM/vị trí cho mục đích giám sát/debug; vòng điều khiển tốc độ kín qua Motor_Speed_Task() (tăng/giảm duty dần để bám target_rpm) đã được viết sẵn nhưng chưa được gọi trong luồng chính (target_rpm mặc định = 0).

13.Máy trạng thái vận hành (RunState_t)

Toàn bộ logic điều khiển cấp cao nằm trong hàm Run_Task(), điều phối bởi biến run_state. Bảng dưới đây liệt kê đầy đủ 10 trạng thái có trong enum, phân biệt trạng thái ĐANG được sử dụng (chế độ test tay hiện tại) và trạng thái ĐÃ VIẾT SẴN cho production (đang bị bỏ qua vì chưa có cảm biến dòng thật):

14.Biến trở panel điều khiển (VR1..VR6)

6 biến trở vật lý trên panel điều khiển được đọc qua ADC (giá trị thô 0..4095) và quy đổi sang đơn vị kỹ thuật bởi 3 hàm tiện ích (VR_ScaleDutyPercent, VR_ScaleStepsPercent, VR_ScaleTimeMs - nội suy tuyến tính trong khoảng min/max cấu hình sẵn):

15.Giao tiếp UART3 (debug log + khung lệnh)

USART3 (115200bps, DMA cả TX lẫn RX) đảm nhận 2 vai trò độc lập:

15.1. Xuất log debug (hướng MCU -> PC)

Tất cả đều gửi qua BSP_UART_SendDMA() (bắt đầu truyền bất đồng bộ bằng HAL_UART_Transmit_DMA), chỉ gọi khi BSP_UART_TxReady() (huart3.gState == HAL_UART_STATE_READY) trả về đúng - tránh chồng lệnh gửi trong khi DMA còn đang truyền dòng trước.

15.2. Nhận lệnh điều khiển (hướng PC -> MCU)

command.c cài đặt một bộ phân tích khung (frame parser) dạng máy trạng thái, đọc byte từ vòng đệm DMA RX (BSP_UART_RxRead() - tính toán vị trí ghi hiện tại qua con trỏ DMA __HAL_DMA_GET_COUNTER() để suy ra các byte mới đến, không cần ngắt RX). Định dạng khung:

[STX = 0xAA] [CMD] [LEN] [PAYLOAD x LEN byte] [CRC8]

CRC8 tính trên (CMD, LEN, PAYLOAD) theo đa thức 0x07. Các lệnh hiện hỗ trợ:

Gói tin sai CRC hoặc vượt độ dài payload tối đa (16 byte) sẽ bị âm thầm hủy (không dispatch), quay về chờ STX mới. Lệnh hợp lệ được lưu vào pending_command và chỉ được Command_GetPending() trả về MỘT LẦN DUY NHẤT (tự động reset về CMD_NONE sau khi đọc) - hoạt động như một cạnh lên ảo, tương tự forward_rising/reverse_rising của nút bấm vật lý.

16.Nhật ký bring-up: các lỗi đã xử lý

Danh sách các vấn đề thực tế đã gặp và cách xử lý trong quá trình đưa hệ thống lên phần cứng thật, theo thứ tự thời gian - giúp hiểu vì sao một số đoạn code hiện có dạng như vậy.

#1 - UART3 không gửi dữ liệu sau lần đầu

Triệu chứng: chỉ gửi được 1 dòng log, sau đó BSP_UART_TxReady() luôn trả về sai.
Nguyên nhân: thiếu USART3_IRQHandler() và HAL_NVIC_EnableIRQ(USART3_IRQn) - không có ngắt để HAL báo hoàn tất DMA TX, gState kẹt vĩnh viễn ở trạng thái BUSY.
Xử lý: bổ sung cả 2 phần, đặt trong cặp USER CODE để sống sót qua các lần CubeMX regenerate.

#2 - CubeMX regenerate xóa mất fix thủ công

Triệu chứng: lỗi #1 tái xuất hiện sau khi CubeMX đổi cấu hình chân (PA1/PA2 sang dòng pha B/C).
Nguyên nhân: fix ban đầu nằm NGOÀI cặp USER CODE BEGIN/END, bị CubeMX ghi đè khi regenerate.
Xử lý: chuyển toàn bộ fix vào đúng cặp USER CODE tương ứng.

#3 - ADC đọc gián đoạn về 0

Triệu chứng: giá trị ADC thỉnh thoảng đọc được 0 bất thường.
Nguyên nhân: NbrOfConversion trong adc.c (8) lệch với độ dài DMA transfer trong bsp_adc.c (BSP_ADC_CHANNEL_COUNT = 9), gây trượt chỉ số kênh qua từng vòng quét.
Xử lý: bổ sung cấu hình kênh thứ 9 còn thiếu, đồng bộ NbrOfConversion = 9.

#4 - PA0 không đấu nối vật lý

Triệu chứng: Motor_StallDetected() và log dòng điện đọc giá trị vô nghĩa.
Nguyên nhân: cảm biến dòng pha A (PA0) chưa được lắp đặt trên phần cứng, chân đọc giá trị trôi nổi ngẫu nhiên.
Xử lý: chuyển cả 2 nơi đọc dòng sang MAX(PA1, PA2) - 2 kênh đã xác nhận có đấu thật.

#5 - Chiều THUẬN không tự khởi động

Triệu chứng: chỉ quay được nếu mồi tay theo, dù bảng chuyển mạch đối xứng đúng về logic với NGHỊCH.
Nguyên nhân (xác định qua thực nghiệm): lệch góc điện do 3 cảm biến Hall không đạt hoàn toàn đối xứng cơ khí.
Xử lý: áp dụng kỹ thuật lead-commutation (Hall_ThuanNext()) chỉ cho nhánh THUẬN - xác nhận tự khởi động và chạy đúng nhiều chu kỳ qua logic analyzer (xem mục 6.4).

#6 - Kick 55% gây quá dòng nguy hiểm khi không tải

Triệu chứng: chiều NGHỊCH bị kẹt với dòng cao (đo được PA2max~3428, SSCR_U=1) sau khi thêm kick 55%/300ms.
Nguyên nhân: lúc test CHƯA gắn tải cơ khí thật, rotor không tải tăng tốc quá nhanh ngay từ đầu, vòng lặp debounce Hall không theo kịp tốc độ thực, khiến commutation áp vector cho vị trí đã cũ - vô tình chống lại chiều quay, gây hãm đột ngột và dòng vọt cao.
Xử lý: hạ kick về bằng MOTOR_TEST_DUTY_ACCEL_START (vô hiệu hóa), giữ lại code để dùng khi gắn tải thật (xem mục 10).

#7 - Hiệu chỉnh watchdog stall timeout

Triệu chứng: với timeout 400ms, chiều NGHỊCH (trước đó tự khởi động tốt ở 25%) lại cần mồi tay.
Nguyên nhân: quá trình thắng ma sát tĩnh tự nhiên cần nhỉnh hơn 400ms nhưng dưới 1000ms - watchdog cắt PWM quá sớm, TRƯỚC KHI động cơ kịp tự khởi động.
Xử lý: nâng MOTOR_STALL_TIMEOUT_MS lên 700ms (xem mục 11.2).

#8 - Xác minh bảng chuyển mạch qua máy phân tích logic (Saleae Logic 2)

Xuất CSV từ cả 2 lần test THUẬN và NGHỊCH, đối chiếu với bảng chuyển mạch (có tính đến đảo cực LIN ở mục 7) để kiểm tra 2 điều: (1) không có trường hợp High và Low CÙNG một pha cùng dẫn (shoot-through), (2) cặp pha đang dẫn tại mọi thời điểm khớp đúng với bảng lý thuyết theo Hall/hướng đang áp dụng. Kết quả: 0 trường hợp shoot-through thực sự ở cả 2 chiều (một vài blip 10us đơn lẻ được xác định là nhiễu/rung điện khi chuyển mạch, không phải lỗi thật, vì hằng số thời gian L/R của cuộn dây lớn hơn nhiều so với 10us). Riêng file reversekoquay.csv (một lần test NGHỊCH không quay được) cho thấy watchdog 700ms hoạt động đúng thiết kế - áp dụng vector Hall hợp lệ liên tục suốt ~697ms rồi cắt sạch, không đoản mạch - nhưng rotor vẫn không nhúc nhích, xác nhận đây là trường hợp thiếu mô-men khởi động thật ở đúng vị trí nghỉ đó (không tải), không phải lỗi phần mềm/thời gian.

#9 - Gỡ bỏ Hall_ThuanNext() theo yêu cầu người dùng (25/08/2026)

Bối cảnh: sau khi xác nhận fix "lead commutation" (mục 6.4) giúp chiều THUẬN tự khởi động ổn định, người dùng yêu cầu gỡ bỏ hoàn toàn cơ chế này khỏi code, chấp nhận quay lại hành vi cũ.
Thay đổi: xóa hàm Hall_ThuanNext() và comment giải thích trong motor_commutation.c; 2 vị trí gọi switch (Hall_ThuanNext(hall)) / switch (Hall_ThuanNext(active_hall)) trả về switch (hall) / switch (active_hall) thẳng.
Kiểm chứng: build lại qua Keil ARMCC5 - 0 Error(s), 0 Warning(s), Program Size: Code=14884 RO-data=312 RW-data=172 ZI-data=2332 (giảm 68 byte Code so với bản có Hall_ThuanNext, đúng như dự kiến khi bỏ 1 hàm nhỏ + 2 lời gọi hàm).
Hệ quả chấp nhận: chiều THUẬN có thể quay lại hiện tượng không tự khởi động được ở duty cao (đã ghi nhận #5) - đây là đánh đổi có chủ đích, không phải lỗi phát sinh. Bảng tra cứu "nếu dịch bước" được giữ lại ở mục 6.4.1 để tham khảo nếu cần khôi phục sau này.

#10 - Hạ duty test-spin để kiểm tra lại trạng thái Hall

Bối cảnh: người dùng yêu cầu giảm duty để quan sát log Hall ổn định hơn, giảm rủi ro dòng cao trong lúc kiểm tra.
Thay đổi: MOTOR_TEST_DUTY_ACCEL_START hiện là 8%, MOTOR_TEST_DUTY_RUN 10%, MOTOR_TEST_DUTY_DECEL_MIN 8% (xem mục 17) - MOTOR_KICK_DUTY_PERCENT tự động theo ACCEL_START nên cũng là 8%.
Lưu ý: ở mức duty thấp này, động cơ có thể KHÔNG ĐỦ mô-men tự khởi động (cần mồi tay) - đây là đánh đổi chủ động để ưu tiên quan sát Hall an toàn, không phải lỗi.

17.Bảng tham số hiện hành

Các hằng số quan trọng nhất, trích xuất trực tiếp từ main.c tại thời điểm xuất tài liệu:

18.Tồn đọng và khuyến nghị tiếp theo

1. Đấu nối cảm biến dòng pha A (PA0) và chuyển run_state khởi tạo về RUN_STATE_CAL_FIND_TOP (cũng sửa lại điều kiện nút bấm ở bước 4) để kích hoạt toàn bộ luồng production đã viết sẵn: calibration hành trình, tự động đóng sau khi mở, phát hiện vật cản khi đóng (mục 13).
2. Hiệu chỉnh MOTOR_STALL_ADC_THRESHOLD bằng dữ liệu thực tế (log ADC=xxxx qua UART) - giá trị 2048 hiện chỉ là placeholder giữa thang đo, chưa đối chiếu với mạch cảm biến dòng thật (mục 11.1, mục 17).
3. Thử nghiệm lại cơ chế kick khởi động với tải cơ khí thật (cánh cửa thật thay vì trục quay tự do) - kick 25% (hiện tại) có thể không đủ mô-men, nhưng 55% đã gây mất đồng bộ debounce Hall lúc không tải; cần tìm lại mức phù hợp khi đã có tải và có thể cần điều chỉnh thêm tốc độ vòng lặp debounce để theo kịp tốc độ rotor cao hơn.
4. Xử lý trường hợp NGHỊCH cần mồi tay ở một số vị trí nghỉ rotor - đã xác nhận qua logic analyzer là thiếu mô-men khởi động thật (không phải lỗi phần mềm), chỉ xảy ra khi không tải. Cần đánh giá lại sau khi gắn tải cơ khí thật; nếu vẫn còn, các hướng xử lý đã đề xuất gồm: chấp nhận cần mồi tay trên bàn test không tải / thử kick mức trung gian (~40%) / ưu tiên gắn tải thật để kiểm tra lại trước.
5. Nâng cấp dead time từ vòng lặp NOP (không chính xác tuyệt đối, phụ thuộc ngắt/trình biên dịch) sang DWT cycle counter hoặc timer riêng, trước khi triển khai ở mức công suất/duty cao hơn mức test hiện tại (mục 6.2).
6. Lưu ý quy trình CubeMX: mỗi lần regenerate từ file .ioc, kiểm tra lại các fix thủ công quan trọng (đặc biệt USART3 IRQ, xem mục 16 #1-#2) vẫn còn nguyên trong cặp USER CODE, tránh lặp lại lỗi đã gặp.

Tài liệu này phản ánh trạng thái mã nguồn và kết quả kiểm chứng phần cứng TẠI THỜI ĐIỂM cập nhật (25/08/2026). Các giá trị hằng số, kết luận chẩn đoán và hướng khuyến nghị cần được đối chiếu lại với mã nguồn/dữ liệu đo đạc mới nhất trước khi sử dụng cho quyết định kỹ thuật tiếp theo.