Làm thế nào để bạn xác định nếu một vi điều khiển mới bị lỗi?

Tôi chưa bao giờ xử lý các bộ phận bị lỗi từ eo biển, nhưng 3 chiếc Atmel ATmega164A mới mà tôi nhận được đã thể hiện hành vi cực kỳ kỳ quặc.

Tôi đã thu hẹp nó xuống một cái gì đó để làm với đồng hồ và hóa ra tín hiệu đồng hồ thu được từ bộ dao động bên trong được cho là "hiệu chuẩn nhà máy" đang dao động trong khoảng 650-700 kHz thay vì mức 1 MHz chắc chắn. Tôi đã có thể ghi vào byte hiệu chuẩn để có được mức này rất gần với 1 MHz (vẫn có một số jitter) và hầu hết mọi thứ đều hoạt động nhưng các UART chỉ không hoạt động đúng, chúng dường như phát ra một luồng xung ngắn liên tục bất kể những gì bạn yêu cầu họ làm.

Tôi đã xử lý phiên bản năng lượng thấp của vi điều khiển này trước đây (164P) với các vấn đề không và đã quyết định thả nó vào vị trí và kiểm tra đầu ra xung nhịp trên đó, và 1 MHz chắc chắn không có jitter. Tôi đang nghiêng về kết luận rằng các chip 164A này bị lỗi, nhưng liệu có bất kỳ thử nghiệm nào khác tôi có thể thử để xác nhận điều đó không?

Chỉnh sửa: Chỉ cần nghĩ rằng tôi mô tả quá trình tôi đang đo đồng hồ. Tôi đã kích hoạt bit cầu chì đầu ra đồng hồ và đo pin phù hợp bằng cách lấy mẫu phân tích logic ở tốc độ rất cao. Tôi có một chương trình ghi vào thanh ghi hiệu chuẩn OSCCALvà tôi đã có thể dùng thử & lỗi theo cách của tôi đến 1 MHz.

Chỉnh sửa # 2: Sau khi điều tra thêm, có vẻ như vi điều khiển bắt đầu hoạt động sau một kích thước chương trình nhất địnhngưỡng. Một dự án đơn giản với một tệp nguồn duy nhất nhấp nháy đèn LED có vẻ ổn, nhưng biên dịch và liên kết trong bất kỳ tệp nào khác của tôi (nói thư viện UART hoặc bất cứ điều gì) mà thậm chí không thực hiện lệnh gọi các phương thức đó khiến vi điều khiển hoạt động các hành vi được mô tả ở trên. Kết nối nguồn là tốt và tách rời thích hợp đã được thực hiện. Tôi không có thời gian để gỡ lỗi này thêm nữa vào lúc này, vì vậy chúng tôi đã đi trước với phiên bản năng lượng thấp thay thế. Tôi không chắc chính xác vấn đề có thể là 1) 164A và 164P không tương thích với mã 2) Quy trình lập trình khác nhau đối với hai 3 uC này 3) Đơn vị bị lỗi. Tôi tự tin vào thiết kế bảng của chúng tôi và sẽ loại trừ các vấn đề về điện. Thật không may, tôi thực sự không thể chọn một câu trả lời chính xác vì vậy tôi sẽ để lại câu hỏi này - có lẽ tôi sẽ trở lại vấn đề một lần nữa trong tương lai. Cảm ơn tất cả những người đã cung cấp những nhận xét hoặc câu trả lời sâu sắc, họ có thể phục vụ hữu ích cho người khác với các vấn đề uC ngoài luồng.

Rất hiếm khi có loại thất bại đó. Bạn có thể thấy tiếng ồn lớn hơn một chút trên pin hoặc có pin đó hoàn toàn không hoạt động. Nhưng để có nó "phần nào hoạt động, nhưng không phải là một cách hữu ích" là hiếm. Tôi nghi ngờ có những vấn đề thiết kế đang gây ra vấn đề và có liên quan đến sự khác biệt giữa 164A và 164P. Vì jitter cao, tôi sẽ xem xét những thứ liên quan đến sức mạnh. Có phải tất cả các chân nguồn / gnd được kết nối? Các chân I / O được điều khiển hoặc kéo lên cao hay thấp? Vân vân.

Nhưng vẫn còn khả năng các bộ phận là xấu. Nó hiếm, nhưng không nghe thấy. Cách thực sự duy nhất để nói là lấy thêm một số bộ phận, từ một nhà cung cấp khác và thử chúng. Nếu chúng hoạt động, thì bạn cần điều tra thêm và xem liệu bạn đã giết chúng khi xử lý / hàn hoặc nếu chúng thực sự đến từ Digikey xấu.

Tôi đã từng có một vấn đề rất giống với các bộ phận cơ sở Microchip. Chúng tôi đã làm xáo trộn chương trình ICSP và đang tìm cách xóa phần cắt dao động, gây ra lỗi tổng thể về độ chính xác của đồng hồ bên trong. Đảm bảo rằng vật cố lập trình và / hoặc các công cụ lập trình của bạn đang được kết nối chính xác và đang được sử dụng đúng cách.

Không có cách nào dễ dàng để xác minh độ chính xác của bộ tạo dao động mà không cần lập trình các bộ phận, vì vậy tôi chỉ cần viết một chương trình chuyển đổi cổng tầm thường (một chương trình không làm gì ngoài việc lắc một dòng I / O) và nhờ người khác lập trình các bộ phận, tốt nhất là với phần cứng lập trình khác nhau. Khi bạn xác minh sự lắc lư, bạn có thể phản xạ lại bằng mã của riêng bạn và xem vấn đề còn tồn tại không.