Đây là sơ đồ nguyên lý của S32K144 Elephant Embedded. Vấn đề hiện tại là chương trình không chạy được, flash vẫn luôn trống. Khi nhả nút RESET, điện áp của RESET so với đất là 1 V, rõ ràng là không đúng.
Người bán nói rằng chip đã bị khóa, RESET sẽ có tín hiệu ra; dưới đây là dạng sóng của RESET so với đất.
Nhưng sau khi tôi cho GPT chạy qua quy trình nạp, nó bảo chip không bị khóa, flash có thể nạp vào được, nhưng ngay sau đó lại bị xóa.
Khi tôi đưa toàn bộ quy trình cho GPT, lời giải thích mà nó đưa ra là: chu kỳ reset của chip không phải là watchdog, mà là reset LOCKUP — CPU có flash trống thực hiện lấy lệnh tại 0xFFFFFFFE → lỗi bus → HardFault (handler cũng ở 0xFFFFFFFE) → đệ quy → LOCKUP → reset → lại lặp, với chu kỳ vài trăm micro giây.
Nhưng các cách khắc phục được đưa ra đều không hiệu quả. Vậy các cao nhân có biết cách xử lý không?
IO reset liên tục bị kéo xuống mức thấp? Có phải chương trình bạn nạp đang sử dụng IO PTA5 (RST), phần mềm kéo IO này xuống mức thấp, rồi lại không vô hiệu hóa chức năng reset của IO này trong phần mềm, vì vậy gây ra tình trạng reset và khởi động lại liên tục? Hãy thử nạp một ví dụ bình thường khác vào xem sao.
Điện áp RESET 1V này quả thực có vấn đề. Về nguyên tắc, sau khi nhả nút reset, RESET phải được kéo lên nội bộ hoặc bằng điện trở pull-up bên ngoài lên gần VCC (3,3V). Mức 1V cho thấy hoặc lực pull-up quá yếu, hoặc bản thân chip đang liên tục kéo chân reset xuống thấp.
Nhìn sơ đồ nguyên lý của bạn, điện trở pull-up R7 2,2k đáng lẽ là đủ khỏe, nhưng cần lưu ý rằng chân RESET của S32K144 là chân hai chiều — chính chip cũng có thể chủ động kéo reset xuống thấp. Nếu đúng là đang lặp LOCKUP, chip sẽ tự reset sau mỗi vài trăm micro giây, và dạng sóng răng cưa 1,64kHz bạn thấy trên dao động ký rất có thể chính là hiện tượng đó.
Trước tiên hãy kiểm tra mấy điểm sau:
Đo điện áp hai đầu R7 để xác nhận điện trở pull-up thực sự được nối với VCC_MCU và điện áp bình thường. Đôi khi mối hàn nguồn trên board phát triển bị hở hoặc đầu ra LDO không ổn định sẽ khiến điện áp pull-up không đủ.
Ngắt nút reset, rồi dùng dây nhảy nối trực tiếp chân RESET với VCC, xem chương trình có chạy được không. Nếu chạy được thì vấn đề nằm ở mạch reset; nếu vẫn không chạy thì có thể loại trừ vấn đề ở mạch reset.
Dùng bộ gỡ lỗi J-Link hoặc PE để kết nối trực tiếp, đừng đi qua OpenSDA tích hợp trên board, xem có nhận diện được ID chip không. Đôi khi bộ gỡ lỗi tích hợp sẵn trên board sẽ gây nhiễu quá trình reset.
Kiểm tra VDDA và VREFH; nếu nguồn analog của S32K144 chưa được nối hoặc không ổn định cũng có thể gây ra các hành vi reset kỳ lạ.
Về việc GPT nói đến vòng lặp LOCKUP, về logic là đúng — flash trống quả thực sẽ gây ra tình trạng như vậy. Nhưng vấn đề then chốt là tại sao flash lại trống? Do bộ nạp chưa ghi được vào, hay đã ghi rồi nhưng sau đó lại bị xóa? Nên dùng J-Flash hoặc S32 Design Studio kết nối trực tiếp với chip để xem nội dung flash thực ra là gì. Nếu flash đúng là toàn FF, hãy thử nạp trước một chương trình blink đơn giản nhất, rồi xem nó có chạy được không. Nếu chạy được thì chip chưa bị khóa, mà là vấn đề ở quy trình nạp; nếu không chạy được thì mới xét đến khả năng chip bị hư hoặc bị khóa.
Giải thích của GPT thực ra rất chính xác. Bộ nhớ flash trống trên S32K144 sẽ gây ra thao tác fetch từ một địa chỉ không hợp lệ, dẫn đến HardFault, sau đó leo thang thành Lockup rồi hệ thống khởi động lại. MCU đang chủ động kéo chân reset xuống mức thấp, vì vậy bạn thấy dạng sóng răng cưa 1,64kHz. Để khắc phục, bạn cần một bộ gỡ lỗi hỗ trợ „Connect under reset”. Nếu bạn đang dùng J-Link, hãy mở J-Link Commander và thử lệnh unlock kinetis. Lệnh này sẽ dừng lõi trước khi nó cố thực thi lệnh sai.
Cùng loại board, tháng trước tôi cũng vừa gặp đúng lỗi này. Phân tích bằng GPT của bạn thực ra khá chuẩn, đúng là vòng lặp LOCKUP, nhưng đừng để dạng sóng reset đánh lạc hướng.
Cách tôi xử lý khi đó là: khi nạp, dùng tay giữ nút reset, sau khi bấm Download thì thả tay ra ngay, để chip ghi code vào trước khi reset được giải phóng. Vì một khi đã rơi vào vòng lặp LOCKUP,时序 SWD sẽ rối loạn, trình gỡ lỗi tưởng là đã ghi thành công, nhưng thực ra hoàn toàn chưa ghi vào; lúc đọc lại thì toàn là 0xFF, trông như kiểu “bị xóa”.
Ngoài ra, hãy kiểm tra xem startup file của bạn có phải dành riêng cho S32K144 không. Nếu bạn port code từ STM32 sang, vị trí vector table hoặc linker script có thể không đúng. Địa chỉ bắt đầu Flash của S32K144 là 0x0000_0000, nhưng vector table bắt buộc phải có initial SP hợp lệ và Reset_Handler. Nếu hai giá trị này là 0xFFFFFFFF, chip sẽ đi vào HardFault ngay khi được giải phóng reset.
Bạn cũng nên đo xem 3.3V có ổn định không. Board này dùng nguồn USB đôi khi không đủ tải; khi điện áp tụt xuống dưới 2.8V, việc ghi Flash có thể thất bại trong im lặng, biểu hiện cũng giống kiểu “không nạp được”. Hãy thử đổi sang dây USB ngắn hơn hoặc cấp nguồn 5V bên ngoài.
Là bo mới hả? Cũng có thể là do chưa có chương trình nên nó liên tục reset.
Trước đây tôi dùng ESP32S3 cũng từng bị vậy, module mới, flash còn trống, sẽ liên tục kích hoạt reset. Cách xử lý với ESP32 là nhấn giữ nút BOOT khi cấp nguồn để vào chế độ nạp firmware.
