(Đã cập nhật) Hành vi thiết lập lại kỳ lạ với bộ xử lý ARM9


7

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.

hai dấu vết dao động

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:

ảnh chụp màn hình phạm vi khác, nhưng với dữ liệu nối tiếp rõ ràng hơn

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ả.


"Thú vị" ... đó là tất cả những gì tôi phải nói.
Kellenjb

1
có lẽ là một câu hỏi ngớ ngẩn nhưng mạch thiết lập lại của bạn (nút) không có điện trở kéo lên trên nó phải không? Tôi có nghĩa là khi nút không được nhấn, pin thiết lập lại không nổi. Ngoài ra, bạn cũng có thể thử giới hạn gỡ lỗi trên nút đặt lại để loại trừ hành vi kỳ lạ do nảy dòng thiết lập lại.
Đánh dấu

(Không phải là một câu hỏi ngớ ngẩn-- đó là một trong những điều đầu tiên tôi đã kiểm tra.) Vâng, có một nút kéo lên. Không có giới hạn tranh luận, nhưng tôi đã nhìn kỹ vào cạnh tăng, và nó không bị dội lại. Lỗi xảy ra gần 1 giây sau khi tôi nhả nút, vì vậy tôi nghĩ rằng tôi có thể loại trừ.
pingswept

2
Có lẽ tôi đã bắt đầu trích xuất mã từ u-boot để tìm ra nơi nó gặp sự cố ... Có lẽ bộ điều hợp JTAG của bạn thực hiện thiết lập lại sau đó tạm dừng CPU trong một thời gian - đưa ra một cái gì đó khác trên bảng để khởi động đúng cách
Toby Jaffey

1
JTAG đang ảnh hưởng đến nó, điều này chỉ cho bạn biết chắc chắn bạn sẽ có thể tìm thấy thứ gì đó liên quan trong mã uboot.
Kortuk

Câu trả lời:


6

Nhìn vào bảng dữ liệu:

14.3.4.5 Thiết lập lại Watchdog Thiết lập lại Watchdog được nhập khi xảy ra lỗi watchdog. Trạng thái này kéo dài 3 chu kỳ Đồng hồ chậm.

Khi trong Thiết lập lại cơ quan giám sát, việc xác nhận các tín hiệu đặt lại phụ thuộc vào bit WDRPROC trong WDT_MR: Nếu WDRPROC bằng 0, Xác lập lại bộ xử lý và Đặt lại ngoại vi được xác nhận. Dòng NRST cũng được khẳng định , tùy thuộc vào chương trình của trường ERSTL. Tuy nhiên, mức độ thấp dẫn đến NRST không dẫn đến trạng thái Đặt lại người dùng.

Có thể là cơ quan giám sát đang bắn và lái dòng thiết lập lại?


Điều tiếp theo tôi sẽ đọc là về đồng hồ bấm giờ, chúng có thể gây ra sự cố kỳ lạ, nhưng tôi không chắc liệu JTAG có vô hiệu hóa Watchdog hay không và khiến vấn đề dừng lại.
Kortuk

4

Đây có thể là một cú sút xa. Trên một vi điều khiển cấp thấp hơn nhiều, PIC, tôi đã giúp những người có thiết lập lại lạ nhiều lần do pin lập trình điện áp thấp được kích hoạt.

Khi một lập trình viên được kết nối, nó giữ các đường tương tự như thế này ở điện áp đặt, khi lập trình viên bị ngắt kết nối, họ có thể dễ dàng nổi. Trên một dự án khi thiết bị vượt qua kim loại, nó sẽ thiết lập lại. Họ đã không kiểm tra LVP khi tôi yêu cầu họ, họ làm việc thêm 2 tuần nữa và sau đó vô hiệu hóa nó và vấn đề đã được giải quyết.


Tôi không nghĩ rằng đây là một cú sút xa. Nó có thể không phải là LVP hoặc pin tương tự, nhưng bất kỳ đầu vào nổi. Chúng tôi đã có một PowerPC bị chết với đầu vào I / O chung chỉ vì mức độ của đầu vào sẽ được kiểm tra sớm trong mã.
Andrey

2

Các dòng JTAG có phải là bất kỳ thiết bị nào được kết nối với những thứ mà chúng không được không?

Giống như, nói địa chỉ các tuyến xe buýt?

(Phải mất vài tháng để gỡ lỗi một lần.)


Ý tưởng tốt. Tôi chỉ kiểm tra sơ đồ và bố trí PCB. Tôi không thấy bất kỳ giao cắt đường địa chỉ ngẫu nhiên hoặc kết nối sai. Tôi đã nhận thấy rằng đầu nối JTAG nằm ngay dưới RAM, nhưng chúng được phân tách bằng hai mặt phẳng nguồn và bo mạch khởi động chính xác dưới sự kiểm soát của JTAG. Đó là khi JTAG không hoạt động thì sự cố xảy ra.
pingswept

bạn đang kéo jtag tclk và trst đến trạng thái an toàn?
Tim Williscroft

Có, tất cả các đầu vào JTAG được kéo lên tới 3,3 V, vì vậy trạng thái của chúng không nên thay đổi trừ khi JTAG được gắn và điều khiển chúng.
pingswept
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.