Apa yang dapat menyebabkan mikrokontroler mereset secara tidak terduga?


26

Salah satu variasi bug yang sangat menjengkelkan dalam sistem yang dikendalikan mikroprosesor adalah agar mikroprosesor secara tak terduga melakukan reset. Alat penting untuk men-debug masalah seperti ini adalah daftar kemungkinan penyebabnya. Apa yang dapat menyebabkan mikrokontroler mereset secara tidak terduga?


1
Beberapa jawaban di sini mungkin dapat membantu: electronics.stackexchange.com/questions/30430/... Jenis mikrokontroler apa yang Anda gunakan?
Jon L

Saya biasanya menggunakan dsPIC. Tapi saya tidak mencoba untuk men-debug sesuatu yang khusus saat ini, hanya menyusun daftar referensi masalah potensial.
Stephen Collings

2
apakah ini pertanyaan pekerjaan rumah?
old_timer

1
@dwelch Mungkin untuk seseorang di suatu tempat, tetapi tidak untuk saya atau murid saya.
Stephen Collings

1
@Vorac harus membaca bahwa Atmel tidak dapat berkomitmen untuk menjaga URL tetap andal.
Kaz

Jawaban:


51

Pada chip PIC dan dsPIC, saya telah mengamati penyebab-penyebab reset tak terduga berikut.

Perangkat keras:

  • Atur ulang pin yang didorong rendah atau mengambang. Periksa hal-hal yang sudah jelas terlebih dahulu!
  • ESD coupling ke dalam pin reset. Saya telah melihat ini terjadi ketika peralatan yang sama sekali tidak terkait dihidupkan di meja yang sama. Pastikan ada cukup kapasitansi pada pin reset, mungkin sebanyak 1 uF.
  • ESD menghubungkan ke pin prosesor lainnya. Probe lingkup khususnya dapat bertindak sebagai antena, memasangkan noise ke dalam chip dan menyebabkan reset aneh. Saya pernah mendengar laporan tentang kode reset "opcode tidak valid".
  • Sambungan solder buruk / jembatan terputus-putus. Bisa kehilangan atau korslet power rail, baik pada prosesor atau di tempat lain di papan tulis.
  • Power rail glitch / noise. Dapat disebabkan oleh sejumlah masalah eksternal, termasuk regulator yang rusak atau penurunan pasokan hulu. Pastikan rel daya memberi makan prosesor stabil. Mungkin memerlukan lebih banyak topi di suatu tempat, mungkin topi decoupling langsung pada prosesor.
  • Beberapa mikrokontroler memiliki pin Vcap, yang tidak boleh dihubungkan ke VDD dan harus memiliki kapasitor sendiri. Gagal menyambungkan pin ini dengan benar mungkin memiliki hasil yang tidak terduga.
  • Mengemudi input analog negatif melewati batas tertentu menyebabkan reset yang melaporkan dalam RCON seperti brownout. Hal yang sama mungkin berlaku untuk input digital.
  • DV / dt yang sangat tinggi pada konverter daya terdekat dapat menyebabkan reset brownout. (Lihat pertanyaan ini .) Saya telah melihat ini dalam dua kasus, dan dalam satu kasus saya dapat melacaknya ke kopling kapasitif. Sebuah IGBT beralih 100-200 amp, dan pada saat mematikan beberapa sirkuit umpan balik melihat beberapa mikrodetik kebisingan, pergi dari 2V ke lebih dari 8V pada prosesor 3.3V. Menambah tutup filter pada rel umpan balik itu membuat reset berhenti. Orang bisa membayangkan bahwa menambahkan filter dV / dt di transistor mungkin memiliki efek yang sama.

Perangkat lunak:

  • Pengawas waktu. Pastikan pengawas waktu dibersihkan cukup sering, terutama di cabang kode Anda yang mungkin membutuhkan waktu lama untuk dieksekusi, seperti menulis EEPROM. Uji untuk ini dengan menonaktifkan pengawas untuk melihat apakah masalahnya hilang.
  • Dibagi nol. Jika Anda melakukan operasi pembagian apa pun dalam kode Anda, pastikan pembagi tidak akan pernah sama dengan nol. Tambahkan cek batas sebelum pembagian. Jangan lupa bahwa ini juga berlaku untuk operasi modulo .
  • Stack overflow. Terlalu banyak panggilan fungsi bersarang dapat menyebabkan sistem kehabisan memori dinamis untuk stack, yang dapat menyebabkan crash pada titik-titik yang tidak biasa dalam eksekusi kode.
  • Stack underflow. Jika Anda memprogram dalam assembler, Anda dapat secara tidak sengaja menjalankan lebih banyak PENGEMBALIAN daripada Anda melakukan PANGGILAN.
  • Tidak ada interupsi rutin. Jika interupsi diaktifkan, tetapi tidak ada rutin interupsi yang ditentukan, prosesor dapat mengatur ulang.
  • Tidak ada jebakan rutin. Mirip dengan rutin interupsi, tetapi cukup berbeda saya daftar secara terpisah. Saya telah melihat dua proyek terpisah menggunakan dsPIC 30F4013 yang mengatur ulang secara acak, dan penyebabnya dilacak ke perangkap yang disebut tetapi tidak terdefinisi. Tentu saja, sekarang Anda memiliki pertanyaan tentang mengapa perangkap disebut, yang bisa berupa sejumlah hal, termasuk kesalahan silikon. Tetapi mendefinisikan semua penangan perangkap mungkin harus menjadi langkah awal yang baik dalam mendiagnosis pengaturan ulang yang tidak dapat dijelaskan.
  • Fungsi penunjuk kegagalan. Jika pointer fungsi tidak menunjuk ke lokasi yang valid, mendereferensi pointer dan memanggil fungsi yang ditunjuk dapat menyebabkan reset. Salah satu penyebab lucu dari ini adalah ketika saya menginisialisasi struktur, dengan nilai berturut-turut dari NULL (untuk penunjuk fungsi) dan -1 (untuk int). Koma diketik, sehingga fungsi pointer benar-benar diinisialisasi ke NULL-1. Jadi jangan berasumsi bahwa hanya karena itu CONST itu harus mengandung nilai yang valid!
  • Indeks array tidak valid / negatif. Pastikan Anda melakukan batas memeriksa semua indeks array, baik batas atas dan bawah, jika berlaku.
  • Membuat array data dalam memori program yang lebih besar dari bagian terbesar dari memori program. Ini bahkan mungkin tidak menimbulkan kesalahan kompilasi.
  • Casting alamat struct ke pointer ke tipe lain, mendereferensi pointer itu, dan menggunakan pointer berdereferensi sebagai LVALUE dalam sebuah pernyataan dapat menyebabkan crash. Lihat pertanyaan ini . Agaknya, ini juga berlaku untuk perilaku tidak terdefinisi lainnya.

Pada beberapa dsPIC, register RCON menyimpan bit yang mengindikasikan penyebab reset. Ini bisa sangat membantu saat debugging.


1
@reset pin: pin reset mengambang dikenal untuk mengatur ulang palsu. Ikat selalu ke Vcc melalui resistor.
jippie

4
Ini adalah daftar yang sangat lengkap. Saya percaya dalam pengalaman saya dengan AVR bahwa sebagian besar jika tidak semua situasi yang sama akan menyebabkan hasil atau pengaturan ulang yang tidak terduga.
HL-SDK

4
Biarkan saya menambahkan satu lagi untuk pemrograman bahasa Assembler - Daftarkan PUSH dan POP yang tidak tertandingi dari tumpukan.
Michael Karas

2
Beberapa lagi: di bawah perangkat keras, reset brownout. Di bawah perangkat lunak, instruksi pengaturan ulang perangkat lunak. Keduanya tersedia di beberapa mikrokontroler.
tcrosley

2
Satu lagi untuk daftar: ponsel yang ditempatkan di dekat kabel dapat menyebabkan tegangan yang sangat signifikan pada saluran yang digerakkan dengan lemah. Jika Anda memiliki saluran reset melalui kabel (misalnya sehingga satu papan dapat memaksa reset yang lain), ponsel di dekat kabel dapat memicu reset jika misalnya menerima panggilan.
supercat

7

Pin-RESET harus digerakkan dengan benar oleh sirkuit reset yang memonitor tegangan over / under dan menciptakan sinyal reset yang cukup lama. Dengan mengingat hal itu, pengalaman saya dengan reset perangkat keras yang tidak terkontrol berasal dari:

  • Crosstalk dari beralih jalur ke pin / jalur RESET (buat pendek)
  • Pergeseran / putaran arde yang disebabkan oleh pengaktifan / nonaktif beban arus tinggi eksternal
  • Lonjakan tegangan tidak disaring oleh catu daya dan terlalu pendek untuk mengaktifkan RESET yang benar
  • Mengganti muatan eksternal dengan mikrokontroler yang menyebabkan masalah di atas (terutama pada beban induktif seperti motor on / off, relay atau lampu lama (arus masuk)
  • Tegangan / lonjakan arus pada pin mikrokontroler (yang paling buruk adalah osilator) dapat menyebabkan arus balik dan dapat mengganti register internal (sama seperti lonjakan tegangan pada jalur suplai). Secara umum, ketika berinteraksi dengan semacam lingkungan industri, kehati-hatian perlu diterapkan (untuk lebih banyak lihat: http://www.ichaus.biz/wp1_mcu_interface ). Pergeseran level pada IO, filter input, dan output soft switching perlu dipertimbangkan. Membuat jalur suplai bersih memiliki prioritas pertama di sisi perangkat keras. Kemudian RESET dan pin osilator, lalu IO-line. -mm

1
Ground shift hanya menggigitku. Dalam kasus saya, saya memiliki bagian tertentu dari jaringan umum saya yang membawa ~ 100 amp. Mikrokontroler direferensikan ke satu sisi jejak yang tebal, tetapi beberapa sirkuit yang dikendarai mikrokontroler direferensikan ke ujung jejak yang lain. Jejak hanya 3 mOhm, tetapi pada 100 amp yang cukup untuk mendapatkan perbedaan 300 mV antara mikro dan periferal yang dikendarainya. Mengarahkan ulang periferal menjadi umum ke ujung yang sama dari jejak itu sebagai pengontrol, dan semuanya baik-baik saja sekarang. Tidak ada yang namanya simpul pada arus itu.
Stephen Collings

4

Satu kemungkinan tambahan yang tidak saya lihat dalam daftar ini, adalah perangkat yang mendukung ICSP. Jika pull up yang tidak memadai digunakan pada saluran yang memicu dalam mode pemrograman serial sirkuit, kadang-kadang dimungkinkan untuk masuk ke mode itu secara acak. Ini mengarah ke reset interval pendek nanti ketika tidak ada pembaruan program dikirim ke saluran penerima serial yang ditunjuk. Saya menduga timer pengawas internal mengatur ulang jika ICSP dimulai dan tidak ada data pemrograman yang dikirim. Ini adalah kesalahan yang saya buat dan menghabiskan banyak waktu mencari dengan 16F876.


3

Pastikan jika Anda menggunakan chip logika CMOS atau TTL di sirkuit Anda bahwa mereka memiliki kapasitor decoupling yang memadai di Vdd dan ground (biasanya 0,1 uF). Saya menggunakan CD4021 dalam desain dan ketika sedang digunakan, ternyata itu menyebabkan beberapa lonjakan yang menyebabkan mikroprosesor restart. Kemudian siklus itu akan berulang. Ini juga mengapa itu ide yang baik untuk menempatkan urutan pengujian yang jelas (seperti mengedipkan LED dan mematikan beberapa kali) di awal kode Anda sehingga Anda tahu bahwa mikroprosesor bekerja dan mengeksekusi kode.


2

Ini adalah salah satu hal langka yang mungkin muncul:

Saya punya proyek yang melibatkan mikrokontroler dan secara sporadis akan me-reset sendiri. Singkatnya, ternyata beberapa opsi harus diaktifkan atau dinonaktifkan jika tidak, reset dapat terjadi. Saya hanya menemukan ini dengan membaca errata setelah menyerah pada hal-hal lain.

Sekarang saya membuat kebiasaan untuk membaca errata bahkan sebelum saya memutuskan untuk menggunakan chip untuk mengetahui apa yang saya dapatkan dan jika itu sesuatu yang bisa saya kelola. Sayangnya, setelah lulus, saya tidak benar-benar memiliki orang untuk mendidik saya tentang praktik umum sehingga banyak pembelajaran dunia nyata saya telah melalui kegagalan dan frustrasi.


Saya bahkan tidak menyadari bahwa pertanyaan ini sudah lama dan jawaban sudah diberikan. Ups.
efox29
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.