Tôi đang làm việc để gỡ lỗi một vấn đề khởi động với bảng Atmel AT91SAM9G20. Mọi thứ diễn ra tuyệt vời trong 700 ms đầu tiên hoặc lâu hơn. Có vẻ như khoảng 700 ms sau khi thiết lập lại, bộ xử lý đóng băng. Điều gây tò mò là CPU điều khiển dòng thiết lập lại sau khi tôi nhả nút đặt lại.
Đây là một ảnh chụp phạm vi cho thấy những gì đang xảy ra. Dấu vết màu vàng là dòng thiết lập lại. Lần nhúng đầu tiên là thời gian tôi thực sự giữ nút reset. Lần nhúng thứ hai là, tôi tin rằng, được tạo ra bởi CPU.
Dấu vết màu xanh là dữ liệu nối tiếp ra khỏi CPU. Hai vụ nổ đầu tiên đến từ bộ tải khởi động ban đầu. Sự bùng nổ thứ ba là U-boot bắt đầu. CPU dừng gửi các ký tự khi cụm màu xanh thứ ba kết thúc.
Nếu tôi diễn giải các dấu vết một cách chính xác, điều này có nghĩa là dòng đặt lại ở mức thấp gần như chính xác thời gian mà bộ xử lý đang tải U-boot từ flash NAND.
Tôi có một vài câu hỏi:
- Đây có phải là loại thiết lập lại kiểm soát CPU bình thường?
- Bất kỳ đề xuất về làm thế nào để gỡ lỗi này?
Một vài chi tiết khác: Tôi nên nói thêm rằng tôi đã nhìn vào đường ray điện và chúng trông sạch sẽ. Các hành vi dưới đây là tái sản xuất. Tôi có thể thay đổi độ dài của lần đặt lại ban đầu (màu vàng) trong vài giây và phần còn lại của hành vi xảy ra theo cách tương tự. Nếu tôi cắm cáp JTAG, hành vi sẽ thay đổi - đôi khi nó khởi động, đôi khi không, nhưng sau vài giây, JTAG sẽ xử lý và bộ xử lý bị dừng.
Theo JTAG, tôi có thể khởi động thành công. Đây là một khởi động được kiểm soát JTAG thành công trông như thế nào:
Lưu ý rằng thời gian là khác nhau và tôi không nhấn nút đặt lại - phần mềm được kiểm soát. Các thiết lập lại nhúng tương tự xảy ra. Trong cả hai trường hợp, độ dài khoảng 500 ms.
Cập nhật (vẫn còn khó khăn)
Được khuyến khích bởi gợi ý của ông Taffey dưới đây, tôi đã điều tra bộ đếm thời gian theo dõi và bộ điều khiển thiết lập lại chi tiết hơn. Bộ đếm thời gian watchdog trên thực tế bị vô hiệu hóa bởi bộ tải khởi động đầu tiên; Tôi khá chắc chắn rằng mã đang được thực thi bởi vì nó xảy ra trước khi văn bản được gửi ra cổng nối tiếp gỡ lỗi và tôi có thể đọc văn bản thành công.
Khi đọc về các chi tiết của bộ điều khiển thiết lập lại, tôi biết rằng bộ xử lý có nhiệm vụ lấy quyền kiểm soát của pin reset và kéo nó xuống thấp trong một khoảng thời gian ngắn. Điều này là để đảm bảo rằng các phần cứng khác trên bo mạch nghe cùng dòng nhận được thiết lập lại đủ lâu. Đi sâu vào U-boot, tôi thấy rằng thời lượng thiết lập lại được đặt thành 0x0D bằng trường ERSTL:
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
(AT91_RSTC_ERSTL & (0x0D << 8)) |
AT91_RSTC_URSTEN);
Bảng dữ liệu giải thích rằng thời lượng được đặt thành 2 ^ (ERSTL + 1) thời gian đồng hồ chậm.
Thời lượng đặt lại trông dài khoảng 500 ms, tinh thể đồng hồ chậm là 32768 Hz và Google cho tôi biết rằng nhật ký (0,500 * 32768) / log (2) = 14 và 0x0D + 1 = 14, vì vậy tất cả đều có ý nghĩa.
Tôi nghĩ vấn đề thực sự có thể là sự cố U-boot; thực tế là nó xảy ra ngay sau khi thiết lập lại này có lẽ không liên quan. Điều khó hiểu là tại sao U-boot chỉ bị sập khi JTAG không được kết nối.
Cập nhật lần thứ hai
Tôi vẫn không biết điều gì sẽ xảy ra hoặc tại sao JTAG làm cho nó hoạt động khác đi, nhưng tôi nghĩ rằng tôi đã tìm ra một cách giải quyết (loại). Có vẻ như sự cố U-boot đang được gây ra theo một cách nào đó bởi đèn flash NAND trên bảng. Tình cờ, phiên bản tiếp theo của bảng, vừa xuất hiện gần đây, sử dụng thẻ nhớ microSD chứ không phải đèn flash NAND để lưu trữ hàng loạt không dễ bay hơi (vâng, có đèn flash NAND bên trong thẻ nhớ microSD, nhưng bạn nhìn thấy điểm).
"Giải pháp" của tôi chỉ là bắt đầu sử dụng phiên bản tiếp theo của hội đồng quản trị. U-boot cũng gặp sự cố về điều đó, nhưng vì những lý do đã biết-- nó được cấu hình để tìm kiếm đèn flash NAND mà nó không thể tìm thấy. Do đó, nó chết một cái chết bốc lửa.
Vì vậy, vấn đề "đã giải quyết." (Mong đợi một câu hỏi khác ngay sau dòng "Làm cách nào để tôi tạo AT91Bootstrap tải U-boot từ đèn flash nối tiếp?" Hoặc "Làm cách nào để U-boot hoạt động với thẻ nhớ microSD?" Hoặc "Tại sao tôi lại làm điều này?" )
Tôi đoán dấu kiểm màu xanh lá cây đi đến Joby vì nhận thấy rằng dòng thiết lập lại có thể được điều khiển bởi vi mô, mặc dù về lâu dài nó không liên quan. Cảm ơn sự giúp đỡ, tất cả các bạn. Tôi rât cảm kich.
Cập nhật lần thứ ba (khoảng một tuần sau)
Gần đây tôi đã làm việc trên các công cụ khác, nhưng tôi đã tìm ra vấn đề cuối cùng là gì. Bí ẩn cuối cùng của tôi, tôi đã tóm tắt ở trên là:
Điều khó hiểu là tại sao U-boot chỉ bị sập khi JTAG không được kết nối.
Trong thực tế, hóa ra tôi đã nhầm lẫn U-boot không gửi các ký tự ra khỏi cổng nối tiếp gỡ lỗi cho sự cố U-boot. Tôi vẫn không hiểu chi tiết, nhưng tôi phát hiện ra rằng đó không phải là JTAG làm cho U-boot hoạt động - đó là điểm chung giữa mạch của tôi và máy chủ USB của PC, mà JTAG đang cung cấp, bởi vì nó chạy qua cổng USB. Trên thực tế, U-boot đã hoạt động tốt trong toàn bộ thời gian, nhưng bất cứ khi nào JTAG bị ngắt kết nối, bộ chuyển đổi cấp RS-232 sang USB mà tôi đã sử dụng sẽ dừng hoạt động, cổng nối tiếp sẽ thất bại và tôi cho rằng U-boot là đã chết. Trong thực tế, tôi phát hiện ra rằng tôi có thể, ví dụ, vẫn gõ các lệnh ping và xem các gói ICMP được tạo ra, mặc dù các ký tự của tôi không lặp lại trên thiết bị đầu cuối.
Tôi không hiểu chính xác điều gì đang xảy ra, nhưng tôi không thực sự quan tâm-- Tôi có thể dễ dàng tìm một cách khác để đọc cổng nối tiếp và trong thời gian ngắn, tôi chỉ có thể kết nối với USB nối đất .
Cảm ơn sự giúp đỡ, tất cả.