AVR flash memory rusak


11

Pertanyaan ini terkait dengan pemrograman ulang AVR itu sendiri .

Info proyek:
Kami memiliki produk bertenaga baterai menggunakan ATMEGA644P. Aplikasi berjalan secara permanen dalam mode tidur dan hanya bangun satu detik (RTC) atau ketika salah satu dari dua jalur interupsi eksternal dipicu.

Perangkat ini memiliki boot-loader yang cukup sederhana yang berkomunikasi melalui UART (menggunakan antarmuka RS232 IC). Ini hanya berfungsi sebagai metode kenyamanan untuk memperbarui firmware sehingga tidak ada programmer perangkat keras ISP yang diperlukan. (Boot-loader mengharapkan telegram checksum yang aman)

Perangkat ini dirancang dengan internal brown-out DISABLED karena itu menggandakan konsumsi daya dan masa pakai baterai yang panjang adalah wajib (saya kira bahwa deteksi brown-out eksternal harus digunakan - desain ulang sedang bekerja).

Masalah:
Setiap beberapa bulan perangkat berhenti bekerja, tidak ada pembaruan firmware yang dilakukan pada perangkat tersebut. Namun, setelah pemeriksaan lebih lanjut, konten flash perangkat tersebut tampaknya rusak. Selain itu, baterai dari beberapa perangkat itu masih bagus, tapi saya tidak ingin mengesampingkan semacam situasi tegangan rendah.

Ini adalah perbandingan konten flash asli (kiri) dengan konten yang rusak (kanan):

Perbandingan flash

Beberapa pengamatan:

  • Blok yang rusak selalu terdiri dari setidaknya satu halaman flash (256 byte) dan halaman diselaraskan. Dengan kata lain: Hanya seluruh halaman yang terpengaruh, bukan byte tunggal.
  • Konten yang rusak membaca 0xFF sebagian besar waktu, tetapi mungkin juga mengandung beberapa nilai lain atau sepenuhnya "acak".
  • Baris kecil di sisi kiri gambar menunjukkan semua area yang terpengaruh. Untuk perangkat ini, ini sekitar sepersepuluh dari total konten flash.
  • Kami memiliki satu perangkat di mana hanya satu halaman yang terpengaruh.

Sangat masuk akal bahwa kondisi di bawah tegangan saat menulis memori flash dapat merusak konten flash. Namun, ini berarti bahwa beberapa instruksi yang peka terhadap flash harus dijalankan.

Mungkin pengontrol memulai ulang secara acak karena kekurangan tegangan dan kode boot-loader berfungsi sepenuhnya tidak dapat diprediksi selama waktu ini. Mengutip beberapa cowok dari forum lain mengenai kekurangan tegangan:

"Ini bukan hanya instruksi acak dari flash yang dijalankan, tetapi periode instruksi acak (tidak ada jaminan bahwa kode dari flash akan dibaca & ditafsirkan dengan benar). Seiring dengan ini bagian lain dari MCU mungkin tidak berperilaku seperti yang dirancang, termasuk perlindungan mekanisme. "

Pertanyaan:
Apakah Anda pikir "perilaku acak selama tegangan rendah dan menjalankan beberapa instruksi mengubah data di halaman flash" - penjelasannya masuk akal? Jika itu masalahnya, mengapa kita tidak melihat kesalahan semacam ini sepanjang waktu hanya sebagai penyebab beberapa masalah perangkat lunak (stack overflow, pointer tidak valid).

Apakah Anda punya ide lain apa yang bisa menyebabkan korupsi semacam ini? Mungkinkah ini disebabkan oleh EMI / ESD?


Pada blok kedua dalam contoh Anda, apakah ada bit yang berpindah dari 1-> 0 atau semua yang semuanya 0> 1 transisi? Saya memiliki skrip yang menghitung ini, tetapi saya tidak akan mengetik semua angka dari tangkapan layar Anda.
markrages

@markrages: Dari melihatnya, 0-> 1 saja. Satu jawaban juga menunjukkan, bahwa itu tampak seperti penghapusan parsial di mana tidak semua bit dibalik ke 1. Terima kasih atas pengamatannya.
Rev1.0

Jawaban:


11

Anda harus perhatikan bahwa blitz tidak ditulis, itu dihapus. Flash yang dihapus penuh dengan 0xFF. 256 byte pertama Anda benar-benar terhapus, wilayah 256-byte ketiga Anda terhapus sebagian (Anda hanya memiliki 0 hingga 1 bit bit dari data yang benar ke yang rusak).

Menurut datasheet , flash ini dapat dihapus halaman (saya biasanya bekerja dengan menghapus-blok lebih besar dari halaman). Seperti yang terlihat di halaman 282, Performing Page Erase oleh SPM cukup mudah.

Anda mungkin tertarik dengan bagian 23.8.1 (Mencegah Korupsi Flash):

Korupsi program Flash dapat disebabkan oleh dua situasi ketika tegangan terlalu rendah. Pertama, urutan penulisan reguler ke Flash memerlukan tegangan minimum untuk beroperasi dengan benar. Kedua, CPU itu sendiri dapat menjalankan instruksi secara tidak benar, jika tegangan suplai untuk menjalankan instruksi terlalu rendah. Flash korupsi dapat dengan mudah dihindari dengan mengikuti rekomendasi desain ini (satu sudah cukup):

  1. Jika tidak perlu pembaruan Boot Loader di sistem, programkan kunci Boot Loader untuk mencegah pembaruan perangkat lunak Boot Loader.
  2. Jaga AVR RESET aktif (rendah) selama periode tegangan catu daya tidak mencukupi.
    Ini dapat dilakukan dengan mengaktifkan Detektor Brown-out internal (BOD) jika volt yang beroperasi sesuai dengan tingkat deteksi. Jika tidak, sirkuit perlindungan reset VCC rendah eksternal dapat digunakan. Jika reset terjadi ketika operasi tulis sedang berlangsung, operasi tulis akan selesai asalkan tegangan catu daya cukup.
  3. Simpan inti AVR dalam mode tidur Power-down selama periode VCC rendah. Ini akan mencegah CPU dari mencoba untuk memecahkan kode dan melaksanakan instruksi, secara efektif melindungi Register SPMCSR dan dengan demikian Flash dari penulisan yang tidak disengaja.

Pengamatan Anda tentang penghapusan sebagian pada halaman ketiga tampaknya masuk akal. Mengenai teks Atmel: Kita semua setuju bahwa BOD tampaknya wajib. Tetapi saya masih tidak yakin tentang penyebab EXACT dari korupsi itu. Bukankah sangat tidak mungkin bahwa controller hanya mengeksekusi (karena tegangan rendah) instruksi khusus ini untuk menghapus halaman flash? Maksud saya, ini bahkan harus terjadi selama eksekusi kode boot loader, karena flashdisk hanya dapat ditulis dari sana. Dan itu membutuhkan urutan tertentu.
Rev1.0

3
Tidak mungkin menjelaskan sumber pasti korupsi: saat Vcc Anda turun, terlalu rendah untuk sepenuhnya menjenuhkan satu transistor dengan yang lainnya. MCU pada dasarnya adalah persamaan logis yang sangat besar. Jika transistor Anda berhenti berperilaku sebagai saklar logis, Anda mengubah persamaan ini. Karena transistor pertama yang melakukan kesalahan tergantung pada doping ASIC Wafer dan gangguan elektromagnetik eksternal, Anda tidak dapat memprediksi apa yang akan terjadi. Untuk mengatasi masalah ini, saat Anda mendesain ASIC, Anda dapat menambahkan bagian analog yang mematikan bagian digital sebelum melakukan kesalahan. Tetapi itu meningkatkan seluruh biaya ASIC.
Jacen

Membingungkan bahwa catatan aplikasi AVR180 External Brown-out Protection menyatakan: "Perhatikan bahwa Program Flash internal AVR® Konten memori tidak pernah terpengaruh oleh tegangan pasokan daya tidak mencukupi". Lebih lanjut: "Karena AVR CPU tidak mampu menulis ke memori programnya sendiri, isi memori Program Flash internal tidak pernah terpengaruh oleh situasi kegagalan daya." - IMO Atmel mengabaikan bahwa ada sesuatu seperti boot loader yang HARUS mengubah flash mem.
Rev1.0

@ Rev1.0 Yah ya, itu sangat tidak mungkin ... itu sebabnya Anda hanya melihatnya di satu perangkat setiap beberapa bulan, daripada semua perangkat sepanjang waktu.
user253751

"Maksudku, ini bahkan harus terjadi selama eksekusi kode boot loader, karena flashdisk hanya dapat ditulis dari sana." - Itu hanya benar jika bit kunci boot ( BLB01dan teman-teman) diatur dengan tepat! Apakah mereka? "Membingungkan ... catatan aplikasi ..." - Catatan aplikasi terkenal tidak bisa diandalkan. Gunakan hanya untuk inspirasi; untuk jaminan, andalkan lembar data (yang juga tidak salah tapi hei).
marcelm

4

Ini adalah masalah yang terkenal, dan mempengaruhi banyak mikrokontroler (bukan hanya Atmel). Perangkat keras kontrol memori flash merusak atau menghapus bagian memori dalam kondisi tegangan rendah. Perbaikan sederhana adalah dengan mengaktifkan perlindungan berwarna cokelat.

Anda harus selalu mengaktifkan perlindungan brown-out pada mikrokontroler sebagai hal yang biasa.


3
Apakah Anda memiliki referensi yang kuat tentang BAGAIMANA dan MENGAPA "hardware kontrol memori merusak atau menghapus bagian dari memori dalam kondisi tegangan rendah"? Ada banyak diskusi forum tentang korupsi kilat tetapi hampir tidak pernah sampai pada sesuatu yang solid, itulah sebabnya saya bertanya di sini.
Rev1.0

Apakah itu masalah di bawah-tegangan chip atau apakah itu terkait dengan eksekusi program yang salah / acak di bagian bootloader yang AFAIK hanya dapat memodifikasi FLASH. Jika yang kedua adalah masalah menonaktifkan eksekusi bootloader melalui FUSE harus menyelesaikan masalah.
TMa

Saya ingat pernah membacanya di errata setidaknya satu mikro MEGA.
pengguna

3

Tegangan di bawah adalah penyebab yang sangat mungkin. Sebagai contoh, saya pernah memiliki sebuah proyek di mana tingkat kecoklatan 1,8 V sering menyebabkan korupsi, dan korupsi ini tidak pernah dapat direproduksi dengan tingkat kecurangan 3,5V.

Perhatikan, bahwa semakin cepat prosesor berjalan, semakin sensitif terhadap masalah tegangan rendah. Jika menurunkan frekuensi CPU adalah pilihan yang tersedia bagi Anda, mungkin patut dicoba.


1
Terima kasih atas jawabannya. Kami akhirnya menggunakan detektor brown-out daya ultra rendah eksternal dan tidak memiliki masalah korupsi sejak itu.
Rev1.0

0

EMC akan menjadi musuh terbesar Anda, jika seseorang tidak mengikuti aturan utama desain PCB. Berikut adalah yang paling penting dari pengalaman saya sendiri: - memblokir kapasitor pada IC apa pun, terlepas dari apa yang produsen katakan kepada Anda dalam lembar data mereka tentang skema infernal, letakkan setidaknya satu di antara 100pF - 1nF pada setiap saluran listrik IC - lakukan area dasar pada setiap lapisan PCB sebanyak mungkin. Area-area tersebut harus dihubungi melalui semua layer melalui vias sesering mungkin, kisi-kisi sebanyak 50mil adalah nilai yang baik. Hubungkan area-area tersebut ke sinyal ground. - Jangan pernah meninggalkan tembaga yang tidak terhubung (mengambang, tidak ada sinyal) di PCB Anda. Kerjanya seperti antena dan devinitif menempatkan radiasi elektro-magnetik ke perangkat - membuat jejak membawa sinyal jam sesingkat mungkin

Temukan lebih banyak detail dengan permintaan mesin pencari seperti "panduan desain PCB bukti emc"

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.