Watchdog independen (IWDG) atau Window watchdog (WWDG)?

15

Saya masih mencari untuk menemukan jawaban untuk pertanyaan ini:

Mengapa sementara MCU stm32 memiliki pengawas yang sempurna (maksud saya Window Watchdog (WWDG)), ada pengawas sederhana (Independent watchdog (IWDG))?

Saya menemukan halaman ini yang mengatakan:

ST Microelectronics memiliki lini perangkat Cortex-M3. M3 telah menjadi sangat populer untuk perangkat tertanam kelas bawah, dan ST's STM32F mewakili bagian-bagian ini (meskipun WDT adalah add-on ST, dan tidak harus mencerminkan implementasi vendor lain). STM32F memiliki dua mekanisme perlindungan yang berbeda. "Independent Watchdog" adalah desain vanilla cantik yang memiliki sedikit manfaat selain kemudahan penggunaan. Tetapi Window Watchdog mereka menawarkan perlindungan yang lebih kuat. Ketika penghitung waktu mundur berakhir, reset dihasilkan, yang dapat dihambat dengan memuat ulang penghitung waktu. Tidak ada yang istimewa di sana. Tetapi jika memuat ulang terjadi terlalu cepat, sistem juga akan mengatur ulang. Dalam hal ini "terlalu cepat" ditentukan oleh nilai satu program ke dalam register kontrol.

Fitur keren lainnya: dapat menghasilkan interupsi sesaat sebelum mengatur ulang. Tuliskan sedikit kode untuk menghentikan interupsi dan Anda dapat mengambil tindakan, misalnya, menempatkan sistem dalam keadaan aman atau mengambil snapshot data untuk keperluan debugging. ST menyarankan menggunakan ISR untuk memuat kembali anjing penjaga - yaitu, tendang anjing agar reset tidak terjadi. Jangan menuruti nasihat mereka. Jika program macet, penangan interupsi mungkin akan terus berfungsi secara normal. Dan menggunakan ISR untuk memuat ulang WDT membatalkan seluruh alasan untuk pengawas jendela.

dan ini :

Seri baru STMicroelectronics 'dari STM32F4 Cortex ™ -M4 CPU memiliki dua pengawas independen. Satu berjalan dari osilator RC internal sendiri. Itu berarti segala macam hal bisa runtuh di CPU dan WDT akan tetap menyala. Ada juga "pengawas jendela" (WWDT) yang membutuhkan kode untuk menggelitiknya, tetapi tidak terlalu sering. Ini adalah cara yang sangat efektif untuk memastikan kode macet yang ditulis secara acak ke mekanisme perlindungan tidak menyebabkan WDT menggelitik, dan WWDT dapat menghasilkan interupsi sesaat sebelum reset ditetapkan.

ok, mari kita lihat di manual referensi :

STM32F10xxx memiliki dua periferal pengawas tertanam yang menawarkan kombinasi tingkat keamanan tinggi, ketepatan waktu, dan fleksibilitas penggunaan. Kedua periferal pengawas (Independen dan Jendela) berfungsi untuk mendeteksi dan menyelesaikan kegagalan fungsi karena kegagalan perangkat lunak, dan untuk memicu pengaturan ulang sistem atau interupsi (hanya pengawas jendela) ketika penghitung mencapai nilai batas waktu tertentu. Watchdog independen (IWDG) diberi clock oleh clock berkecepatan rendah (LSI) khusus dan karenanya tetap aktif walaupun jam utama gagal. Jam pengawas jendela (WWDG) ditentukan dari jam APB1 dan memiliki jendela waktu yang dapat dikonfigurasi yang dapat diprogram untuk mendeteksi perilaku aplikasi yang terlambat atau awal yang tidak normal. IWDG paling cocok untuk aplikasi yang membutuhkan pengawas untuk dijalankan sebagai proses yang sepenuhnya independen di luar aplikasi utama, tetapi memiliki kendala ketepatan waktu yang lebih rendah. WWDG paling cocok untuk aplikasi yang membutuhkan pengawas untuk bereaksi dalam jendela waktu yang akurat.

Jendela pengawas digunakan untuk mendeteksi terjadinya kesalahan perangkat lunak, biasanya dihasilkan oleh gangguan eksternal atau oleh kondisi logis yang tidak terduga, yang menyebabkan program aplikasi mengabaikan urutan normalnya. Rangkaian pengawas menghasilkan reset MCU pada saat berakhirnya periode waktu yang diprogram, kecuali program me-refresh konten downcounter sebelum bit T6 dihapus. Reset MCU juga dihasilkan jika nilai downcounter 7-bit (dalam register kontrol) di-refresh sebelum downcounter mencapai nilai register jendela. Ini menyiratkan bahwa penghitung harus di-refresh dalam jendela terbatas.

Seperti yang Anda lihat, tidak satu pun dari mereka mengatakan bahwa Mengapa ada dua anjing penjaga. jika saya bertanya Apa perbedaan antara kedua pengawas, Anda akan menghitung semua fitur yang dapat Anda lihat di atas dan jika Anda ingin membandingkan keduanya, jelas Pengawas Jendela (WWDG) akan menjadi pemenang! lalu mengapa ada dua anjing penjaga?

Saya ingin tahu bahwa kapan saya harus menggunakan IWDG dan kapan WWDG?

dan adakah alasan yang mengatakan mengapa kami memanggil arloji kedua dengan nama ini -> "Window watchdog"?

Roh
sumber

Jawaban:

23

Pencatat waktu pengawas reguler harus diatur ulang pada suatu waktu sebelum waktunya habis. Jika Anda memiliki 100ms WDT, Anda dapat mengatur ulang setiap 99.9ms atau setiap 10us dan tidak akan pernah habis.

Timer pengawas jendela memiliki a jendela waktu di mana mereka harus diatur ulang. Jika Anda meresetnya terlalu awal atau terlalu terlambat (dari reset sebelumnya) itu akan menyebabkan prosesor mengatur ulang.

Tujuannya, jika tidak jelas, adalah untuk membantu memastikan bahwa kode yang mengatur ulang WDT adalah kode yang dimaksud, beroperasi dengan cara yang dimaksud. Beberapa jenis kondisi tak terduga yang menghasilkan reset WDT frekuensi tinggi tidak akan mencegah sistem dari reset.

Menjalankan WDT dari jam sistem bisa menjadi sedikit masalah - jika jam gagal dan jika tidak ada sirkuit monitor jam independen, hal-hal buruk dapat terjadi. Jam independen untuk WDT berarti bahwa jika sesuatu karena alasan tertentu mulai berjalan pada kecepatan 1/10, WDT akan mengatur ulang (tetapi jendela WDT tidak akan).

Gunakan keduanya jika Anda bisa.

Seperti yang dikatakan halaman tersebut, mengatur ulang WDT dengan ISR umumnya juju buruk (tetapi mungkin dapat diterima jika ISR memverifikasi pengaturan ulang firmware berfungsi sebelum mengatur ulang timer).

Spehro Pefhany
sumber
Benarkah mungkin jam sistem gagal? jika itu terjadi, maka kita bisa memahaminya. jadi, WDT tidak berguna, apakah saya benar? lalu mengapa itu menjadi kekhawatiran?
Roh
1
Jika jam WDT independen memaksa MCU ke kondisi reset (dan kondisi itu aman) maka bencana mungkin dapat dicegah. Kristal MCU korsleting menyebabkan kecelakaan serius pada hari-hari awal (BART, IIRC).
Spehro Pefhany
1
@ Roh: Saya benar-benar melihat jam sistem gagal kembali setelah memasuki mode tidur pada prosesor ini (well, STM32 F0, yang merupakan M0). Ternyata ketika Anda melakukan hal-hal tertentu pada waktu-waktu tertentu jam PLL dapat gagal untuk memulai, dan semuanya berjalan pada kecepatan 1/6.
Nathon
@Nathon Terima kasih. menarik. benar-benar saya benci seri M0. Kedengarannya seperti setiap seri STM memiliki masalah.
Roh
7

Teks yang Anda tempelkan ke pertanyaan memberikan jawaban yang Anda butuhkan.

  1. Anda menggunakan IWDG ketika Anda membutuhkan anjing penjaga sederhana atau ketika Anda membutuhkan anjing penjaga yang benar-benar independen - IWDG memiliki jamnya sendiri, WWDG memperoleh jamnya dari salah satu jam bus - jika gagal atau perangkat lunak Anda mati maka penjaga akan mati.
  2. Anda menggunakan WWDG ketika Anda membutuhkan anjing penjaga yang hanya dapat diatur ulang dalam rentang waktu tertentu (jendela.) Jika perangkat lunak Anda mengatur ulang WWDG terlalu terlambat, maka WWDG akan trip reset prosesor. Jika perangkat lunak Anda me-reset WWDG terlalu awal maka itu juga akan menyebabkan reset prosesor.

Ini disebut "pengawas jendela" karena alasan sederhana bahwa hanya pengawas yang diatur ulang selama periode waktu tertentu (jendela peluang) akan mencegah pengawas mengatur ulang prosesor Anda.

Keduanya melakukan pekerjaan serupa, tetapi mereka melakukannya secara berbeda. Yang Anda butuhkan tergantung pada persyaratan yang harus Anda penuhi.

JRE
sumber
tolong baca komentar saya untuk Spehro Pefhany.
Roh
1
Penghitung waktu yang digunakan WWDG dapat diprogram - Anda dapat mengubah nilainya melalui perangkat lunak Anda. Jika perangkat lunak Anda lepas kendali dan mengubah tingkat APB1, maka jendela waktu akan salah dan pengawas akan mengatur ulang prosesor Anda terus-menerus - kicker anjing penjaga Anda tidak akan pernah (atau hanya karena kebetulan) menendang pengawas pada waktu yang tepat. Program Anda mungkin juga dapat sepenuhnya menonaktifkan jam APB1 atau timer WWDG, dalam hal ini ia tidak akan pernah mengatur ulang prosesor Anda.
JRE
5

Ada alasan lain untuk menggunakan pengawas jendela, baik sebagai gantinya atau atau di samping pengawas independen. WWDG memiliki interupsi yang dapat Anda kaitkan. Ini berarti bahwa, jika kode telah masuk ke loop atau fugue, Anda dapat mengatur breakpoint di WWDG ISR, dan bekerja mundur untuk mencari tahu apa yang dilakukan firmware ketika anjing menggonggong.

Anda tidak dapat melakukan ini dengan IWDG. Seperti namanya, itu tidak tergantung pada prosesor. Alih-alih meningkatkan interupsi, itu hanya menegaskan dan deasserts / RESET - yang tidak memberi Anda banyak petunjuk tentang mengapa itu menyalak. Saya sangat menyarankan pengaturan WWDG dalam parameter operasi normal Anda, ditambah IWDG pada periode yang lebih lama, mungkin 2 * WWDG maksimum. Buat fungsi kick-dog yang menendang keduanya. Dengan cara ini, IWDG hanya menggonggong ketika WWDG terkunci juga, sebagai cadangan akhir.

Jon Green
sumber
1

Pandangan saya:

Gunakan keduanya pada saat yang sama, karena mereka mencari kondisi gagal yang berbeda:

The Independent Watchdog (IWDG) Timer kebutuhan untuk me-reset terus sebelum kali keluar. Dalam praktiknya Anda bisa menambahkan kode reset di mana-mana Anda memiliki status program yang valid, atau sekali dalam loop utama jika Anda memiliki loop utama yang seharusnya sering dieksekusi tanpa ada penundaan besar. Dengan cara ini, jika panggilan Anda untuk mengatur ulang timer (ini kadang-kadang disebut "petting", "menggelitik, atau hanya" mengatur ulang "" anjing penjaga ") tidak terjadi pada waktunya, itu berarti kode Anda baik A) secara tidak sengaja macet suatu tempat Anda tidak melihat --- semacam negara jenis loop tak terbatas yang tak terduga, atau B) sengaja terjebak di suatu tempat Anda diberlakukan melaluiassert()panggilan fungsi dengan loop tak terbatas tertanam yang Anda inginkan kode untuk pergi ketika suatu kondisi penting tidakbenar. Jadi, sekarang kondisi tegas Anda salah, kode Anda sengaja macet di loop tak terbatas, dan pengawas me-reset mikrokontroler untuk mengembalikannya ke keadaan yang valid. Perhatikan juga bahwa "pengawas independen (IWDG) diberi clock oleh clock kecepatan rendah khusus (LSI) dan karenanya tetap aktif bahkan jika jam utama gagal" (lihat ST RM0008 Referensi Manual p493 ).

Namun menurut saya pengatur waktu Window Watchdog (WWDG) dirancang untuk tidak mencari kasus-kasus yang dijelaskan di atas (di mana kode Anda baik secara tidak sengaja atau sengaja [melalui pernyataan] akan "macet" di suatu tempat), tetapi lebih khusus untuk kasus di mana SEBUAH) kode Anda TIDAK mengeksekusi sesuatu yang seharusnya . Dengan kata lain, ia memiliki kesalahan yang menyebabkan loop utama atau subbagian kode lainnya dieksekusi terlalu cepat (atau akan dilewati seluruhnya), sehingga Anda menyetel ulang pengawas terlalu cepat, di luar jendelanya, dan MCU akan diatur ulang. Atau, B)kondisi lain yang bisa dilihat adalah pengaturan waktu yang gagal. Mungkin Anda menyetel ulang pada interval yang tetap, tetapi timer Anda yang digunakan untuk membuat interval ini mendapatkan konfigurasinya secara tidak sengaja berubah di suatu tempat yang seharusnya tidak ada, atau Anda salah mengonfigurasinya di tempat pertama, maka interval waktu akan mati, fix Anda reset interval waktu akan mereset WWDG di luar jendelanya (baik terlalu cepat atau terlambat), dan MCU akan diatur ulang untuk memberi tahu Anda dan / atau memperbaiki kondisi.

Ini adalah pendapat saya. Pikiran atau umpan balik dipersilakan.

Gabriel Staples
sumber
0

"windowed" watchdog hanyalah sebuah watchdog biasa yang melindungi beberapa cara untuk praktik pemrograman yang lebih buruk. Seperti kata orang lain, Anda memiliki "kerangka waktu" yang biasanya dapat disesuaikan di mana "umpan" Anda harus disediakan.

Tak satu pun dari mereka adalah bukti-bukti jika kode Anda dapat masuk dalam loop berkelanjutan secara otomatis. Misalnya. Jika Anda berencana untuk "memberi makan" berdasarkan penghitung waktu terkait IRQ, ini bisa menjadi praktik yang sangat buruk karena kode Anda dapat macet di beberapa do / while di utas surat, sementara interupsi masih dapat memberi makan WWDT Anda dalam urutan yang benar.

Sebenarnya, Anda dapat menggunakan interupsi untuk memberi makan WWDT jika Anda dapat menurunkan prioritas IRQ Anda di bawah kode eksekusi normal seperti yang dapat Anda lakukan pada MIPS (Microchip).

Jika kode Anda mendukung kehidupan, kritis, dll., Lepaskan saja dan gunakan WDT eksternal (lebih disukai berdasarkan T&J).

orfruit
sumber