Apakah mungkin secara fisik menghancurkan mikrokontroler dengan perangkat lunak?

Asumsi:

• Tidak ada sirkuit eksternal yang terhubung (selain sirkuit pemrograman, yang kami anggap benar).
• UC tidak salah.
• Dengan menghancurkan yang saya maksudkan adalah melepaskan asap biru kematian, bukan merusaknya dalam perangkat lunak.
• Itu "normal" UC. Bukan perangkat khusus 1-in-a-juta yang sangat aneh.

Adakah yang pernah melihat hal seperti itu terjadi? Bagaimana itu mungkin?

Latar Belakang:

Seorang pembicara dari sebuah pertemuan yang saya bantu mengatakan bahwa adalah mungkin (dan bahkan tidak sulit) untuk melakukan ini, dan beberapa orang lain setuju dengannya. Saya belum pernah melihat ini terjadi, dan ketika saya bertanya kepada mereka bagaimana itu mungkin, saya tidak mendapatkan jawaban yang nyata. Saya benar-benar ingin tahu sekarang, dan saya ingin mendapatkan umpan balik.

Tentu saja Anda bisa, dengan instruksi HCF !

Yang mengatakan, saya katakan itu tidak mungkin tanpa sirkuit eksternal, terlepas dari daya dan semacamnya.

Bahkan termasuk beberapa koneksi yang tidak sengaja salah mungkin tidak akan memotongnya: jika Anda mengikat semua gpios ke power rail, mengaturnya sebagai output (ke power rail yang berlawanan) yang dapat menghabiskan daya yang cukup banyak. Pin gpio mungkin dilindungi terhadap korsleting dan sehingga tidak ada yang berbahaya akan terjadi.

Merancang sirkuit eksternal yang menghancurkan chip sesuka hati juga tidak sepele. Hal pertama yang terlintas dalam pikiran membutuhkan catu daya tegangan agak tinggi, nmos dan resistor:

^{mensimulasikan rangkaian ini - Skema dibuat menggunakan CircuitLab} Di mana:

• adalah pasokan biasa untuk mikro, beberapa 3v3 ke 5V atau apa pun yang dibutuhkan$V_{CC}$
• HV adalah suplai yang tegangannya jauh di atas peringkat maksimum absolut mikro
• D1 ada untuk melindungi sumber tegangan 3V3 Anda yang berharga
• R1 menarik gerbang MOSFET tinggi ketika mikro tidak menyimpannya ke tanah
• M1 adalah pembunuh yang ditunjuk

operasi sederhana: jika mikro rilis GPIOx M1 menyala, Vcc naik dan chip Anda terbakar. Perhatikan bahwa ini adalah pengaturan yang jelek, misalnya HV harus dihidupkan setelah Anda lebih yakin bahwa GPIOx dipegang dengan kuat ke ground. Beberapa transistor mungkin tidak menyukai beberapa Vgs -5V, dan seterusnya ... Tapi Anda mendapatkan gambarannya.

Penafian: supercat mengatakan itu pertama kali dalam komentar.

Sebenarnya, tidak mungkin untuk menghancurkan fisik sebagian besar MCU, tetapi dimungkinkan untuk memakainya cukup untuk mulai tidak berfungsi sampai ke titik di mana ia tidak dapat digunakan. Saya memiliki pengalaman dengan MSP430 TI, jadi begini:

MCU tersebut memungkinkan memprogram ulang seluruh blitz kapan saja. Tidak hanya mungkin untuk memakai flash dengan menulis ulang jutaan kali sampai gagal, tetapi generator pemrograman flash on-chip dapat menyebabkan kegagalan pada prosesor ujung bawah jika generator pemrograman tidak dikonfigurasi dengan benar. Ini adalah rentang frekuensi yang diperbolehkan untuk pemrograman. Saat berada di luar rentang itu (lebih lambat), waktu pemrograman mungkin menjadi terlalu lama dan menyebabkan kegagalan sel-sel flash. Setelah hanya beberapa ratus siklus, dimungkinkan untuk "membakar" sel-sel flash menyebabkan kegagalan permanen.

Juga, beberapa model memungkinkan untuk melakukan overclock pada inti sehingga mencapai kecepatan yang lebih tinggi dengan meningkatkan tegangan internal. MCU beroperasi dari pasokan tegangan 1,8-3,6V, tetapi intinya sendiri dirancang untuk berjalan pada 1,8V. Jika Anda melakukan overclock inti pada power rail 3.6V sambil mengaktifkan semua I / Os, mengaktifkan semua periferal dan berjalan pada 40MHz yang menyala-nyala (normal adalah maks 25MHz pada model yang lebih besar) dalam kasing yang kecil, Anda mungkin berakhir menggoreng inti karena terlalu panas. Sebenarnya beberapa orang mengatakan bahwa mereka mencapai frekuensi tersebut (biasanya DCO gagal sebelumnya dan chip disimpan, tapi yah ... mungkin).

Cobalah?

Menurut stackexchange - "Apakah benar-benar ide yang buruk untuk membiarkan pin input MCU mengambang?"

Ini menjelaskan beberapa keadaan di mana chip mungkin rusak oleh pin sirkuit terbuka. Sunting: sebuah contoh Spansion Analog and Microcontroller Products mengatakan:

4.1 Input Port / Pin I / O Digital yang Tidak Digunakan
Sangat disarankan untuk tidak meninggalkan pin I / O digital yang tidak terhubung, sementara mereka dialihkan ke input. Dalam hal ini pin tersebut dapat memasuki apa yang disebut kondisi mengambang. Ini dapat menyebabkan arus ICC tinggi, yang merugikan mode daya rendah. Kerusakan MCU juga bisa terjadi.

Kondisi dalam pertanyaan ini adalah pin rangkaian persis terbuka.

Jadi, tugas kita adalah menggerakkan itu dari Mei ke akan merusak pin. Saya pikir itu sudah cukup untuk melampaui 'bricking'.

Salah satu mekanisme yang diidentifikasi dalam jawaban itu adalah menggerakkan pin input ke tegangan nilai-menengah, di mana kedua transistor komplementer sama-sama 'aktif'. Beroperasi dalam mode itu, antarmuka pin mungkin menjadi panas atau gagal.

Pin input memiliki impedansi yang sangat tinggi, dan juga merupakan kapasitor. Agaknya, mereka cukup kopling antara pin yang berdekatan yang beralih pin tetangga cukup cepat dapat mengarahkan muatan ke pin input dan mendorongnya ke keadaan 'panas'. Mungkinkah setengah pin I / O didorong ke keadaan itu menghangatkan chip cukup untuk menyebabkan kerusakan?

(Apakah ada mode, di mana kapasitansi pin cirrcuit terbuka mungkin digunakan seperti pengganda tegangan? Hmm.)

Saya juga berpikir flash yang merusak sudah cukup. Saya pikir itu cukup buruk untuk membuat chip tidak berguna.

Tidak harus semua flash, tetapi hanya halaman yang berisi vektor Power-on, RESET dll. Batas pada satu halaman mungkin perlu beberapa puluh detik.

Saya punya indikasi, tetapi tidak ada bukti kuat) bahwa untuk beberapa MCU mungkin lebih buruk. Saya menghadiri presentasi beberapa tahun yang lalu. Seseorang bertanya mengapa para pesaing menawarkan suku cadang dengan siklus penulisan flash yang jauh lebih tinggi. Presenter (produsen MCU besar yang tidak disebutkan namanya) mengatakan mereka mengambil pendekatan yang jauh lebih konservatif dalam spesifikasi memori flash mereka. Dia mengatakan jaminan mereka didefinisikan pada suhu yang jauh lebih tinggi daripada norma industri. Seseorang bertanya "jadi apa". Pembicara tersebut mengatakan beberapa produk pabrikan akan memiliki usia pakai ulang yang jauh lebih rendah daripada bagian-bagiannya pada suhu yang sama seperti yang mereka gunakan. Ingatan saya 5x akan menjadi <1x. Dia mengatakan itu sangat non-linear. Saya menganggap itu berarti pemrograman pada 80C bukannya 25C akan menjadi "hal buruk".

Jadi, flash menulis ulang dikombinasikan dengan chip yang sangat panas, mungkin juga membuatnya tidak berguna dalam waktu kurang dari 10 detik.

Sunting:
Saya pikir "melepaskan asap biru kematian" adalah kendala yang lebih sulit daripada yang dibutuhkan. Jika salah satu dari: Rangkaian pin RESET, brown-out-detector, power-up circuitry, RC atau osilator kristal (dan mungkin beberapa rangkaian lainnya) dapat rusak, chip akan dianggap tidak berguna.

Seperti yang telah dicatat orang lain, memecah flash akan membunuhnya juga tidak dapat diperbaiki.

"Smoke" terdengar mengesankan, tetapi serangan fatal yang kurang jelas masih berakibat fatal, dan jauh lebih sulit untuk dideteksi.

Salah satu sumber potensial dari kerusakan tersebut adalah SCR latchup, di mana transistor (intrinsik) yang tidak diinginkan dalam sebuah chip berkumpul untuk membentuk semacam TRIAC yang kemudian dapat menenggelamkan banyak arus. Ini dengan mudah dapat meledakkan kabel ikatan, dan saya bahkan melihat perangkat terbungkus plastik tampak bengkok karena panas yang dihasilkan.

Penyebab khasnya adalah menggerakkan (bahkan untuk sementara) input ke atas atau di bawah masing-masing pasokan atau ground rails, tetapi saya kira Anda mungkin melihatnya terjadi jika input dibiarkan mengambang. Dan itu tidak sulit untuk membayangkan sirkuit di mana input mengambang adalah perangkat lunak yang dikendalikan (meskipun itu akan menjadi hal yang sangat konyol untuk memungkinkan).

MUNGKIN bahwa perangkat lunak yang sengaja dibuat untuk tujuan tersebut, ditargetkan pada prosesor yang sangat spesifik, mungkin dapat memaksa overclocking ke titik di mana prosesor akan terlalu panas. Asalkan, tentu saja, bahwa prosesor berisi register kontrol-waktu yang dapat dikonfigurasi perangkat lunak.

TIDAK mungkin bahwa SEMUA prosesor dapat rusak dengan cara ini, tentu saja. Jika itu benar, akan ada miliaran Z80 dan 6800 dan 6502 diletakkan di pinggir jalan oleh tyros penulisan perangkat lunak patuh ketika kita masih mengetik kode mesin secara manual, membuat banyak kesalahan acak.

Ini adalah entri saya untuk merusak mikrokontroler dengan sesedikit mungkin bagian ...

Hanya beralih pin output di beberapa kHz!

Anda mungkin masih tidak melihat asap, tergantung pada mode kegagalan internal.

^{mensimulasikan rangkaian ini - Skema dibuat menggunakan CircuitLab}

--Edit, ditambahkan 22 Agustus -

Sekarang, saya tidak berpikir Anda dapat merusak mikrokontroler dengan kriteria yang diberikan. Tetapi Anda dapat dengan mudah merusak sirkuit eksternal dengan kode yang salah. Contoh yang muncul di benak saya adalah konverter boost sederhana yang saya rancang baru-baru ini ... cukup menjeda kode sementara debugging dapat mempersingkat induktor ke ground melalui MOSFET. POOF

Dalam hal kode mode pengguna biasa, saya rasa Anda tidak bisa menulis apa pun yang akan merusak chip.

Namun, saya ingat hari-hari mikroprosesor yang dapat dihancurkan dalam waktu kurang dari satu menit atau bahkan detik jika heat sink jatuh. Kemudian mereka menambahkan sirkuit pendeteksi panas yang akan menurunkan jam jika bagian terlalu panas. Sekarang kita dapat menggunakan transistor yang jauh lebih banyak daripada yang dapat digunakan sekaligus, chip mampu menghasilkan lebih banyak panas daripada yang bisa dihilangkan oleh heat sink dan manajemen daya serta sirkuit termal yang membuatnya tetap aman. Misalnya, lihat Intel Turbo Boost 2.0. Karena itu, sangat mungkin untuk melelehkan chip jika Anda dapat mem-bypass atau menaikkan batas pada manajemen daya dan sirkuit termal. Jadi, jika ini berada di bawah kendali perangkat lunak (tidak tahu; mungkin ini memerlukan pembaruan BIOS?) Maka Anda dapat menjalankan banyak loop do-nothing paralel, bersama dengan kerja GPU terintegrasi, bersama dengan hardware decoding dan encoding H.264, dan apa pun yang bisa dilakukan chip, sekaligus sampai chip terlalu panas dan mengeluarkan asap biru ajaib.

Saya paling akrab dengan prosesor STM32, jadi ini paling berlaku untuk keluarga itu. Tetapi pendekatan serupa mungkin dilakukan dengan prosesor lain juga:

1. Ada mode proteksi permanen. Jadi jika Anda memprogram bit itu, dan beberapa program tidak berguna ke FLASH, MCU tidak akan pernah bisa digunakan lagi. Saya tidak tahu apakah ini dianggap sebagai 'bricking', tetapi itu melibatkan mekanisme perangkat keras permanen.

2. Pin pemrograman dapat dikonfigurasi ulang sebagai GPIO. Karena pin jam digerakkan oleh perangkat pemrograman, ini dapat digunakan untuk menyebabkan korsleting. Kemungkinan besar itu akan merusak pin tunggal itu, yang menjadi pin pemrograman akan sangat buruk.

3. Seperti disebutkan oleh dirkt, PLL dapat digunakan untuk melakukan overclock prosesor. Ini bisa menyebabkan panas berlebih atau rusak.

Siapa yang pernah mengatakan bahwa itu tidak mengerti seberapa terlibat proses desain dari chip tersebut. Itu tidak berarti bahwa slip up tidak terjadi dan bahwa cakupan kode regresi dan kasus sudut kadang-kadang kehilangan hal-hal, tetapi untuk membuat pernyataan bahwa SEMUA atau bahkan sebagian besar prosesor memiliki cacat ini secara logis meragukan.

Tanyakan kepada diri Anda sendiri, apa yang terjadi ketika over-clocker melebihi persyaratan waktu (dengan asumsi itu tidak terlalu panas). chip gagal, dan mungkin merusak memori dan bahkan akses HDD tetapi pada dasarnya prosesor akan menyala kembali dan bahkan menjalankan OS lagi jika korupsi diperbaiki. Jadi, jenis mikrokode yang dirancang dengan baik apa yang dapat menyebabkan gangguan LEBIH dari skenario ini? - Jawabannya sangat mungkin tidak ada.

TLDR; Semua prosesor memiliki kesalahan ini - BUKAN

Saya percaya bahwa secara fisik dimungkinkan untuk menghancurkan mikro-controller (MC) dengan perangkat lunak. Semua yang diperlukan, adalah kombinasi MC untuk mengeksekusi loop "ketat" instruksi yang menyebabkan utilisasi 100%, dan heat-sink "cacat" yang memungkinkan panas di dalam chip untuk menumpuk. Apakah kegagalan itu memakan waktu detik, menit atau jam, akan tergantung pada seberapa cepat panas menumpuk.

Saya memiliki komputer laptop yang hanya bisa saya gunakan 50% pemanfaatan berkelanjutan. Jika saya melebihi ini, komputer dimatikan sendiri. Ini berarti bahwa pada penggunaan 50% suhu MC di bawah titik pemicu yang ditetapkan. Saat penggunaan meningkat, suhu MC meningkat hingga titik pemicu tercapai. Jika sirkuit pemutus termal tidak berfungsi (atau tidak ada), suhu MC akan terus meningkat hingga hancur.

^{mensimulasikan rangkaian ini - Skema dibuat menggunakan CircuitLab}

#include <avr/io.h>

int main(void)
{
    DDRB |= _BV(2) | _BV(4);
    PORTB |= _BV(2);
    PORTB &= ~_BV(4);
    for (;;);
}

Kode di atas menyebabkan MCU mendorong PB2 tinggi sambil menarik PB4 rendah, dan ini menciptakan korsleting dari VDD ke PB2 ke PB4 ke GND dan dengan cepat driver port PB2 dan / atau PB4 akan menggoreng. Hubungan arus pendek mungkin merupakan kesalahan tidak bersalah seperti jembatan solder yang tidak disengaja.