Чи можливо фізично знищити мікроконтролер за допомогою програмного забезпечення?

Припущення:

• Жодна зовнішня схема не підключена (крім схеми програмування, яку ми вважаємо правильною).
• uC не є несправним.
• Під руйнуванням я маю на увазі звільнення синього диму від смерті, а не забиття його в програмному забезпеченні.
• Це "звичайний" UC. Не дуже дивний пристрій на мільйон із цільовим призначенням.

Хтось коли-небудь бачив, щоб щось подібне сталося? Як це можливо?

Фон:

Доповідач зустрічі, якому я допомагав, сказав, що це можна (і навіть не так важко) зробити, і деякі інші люди погодилися з ним. Я ніколи не бачив, щоб це сталося, і коли я запитав їх, як це можливо, я не отримав реальної відповіді. Мені зараз дуже цікаво, і я хотів би отримати відгуки.

Звичайно, ви можете, з інструкцією HCF !

Тим не менш, я кажу, що це неможливо без будь-якої зовнішньої схеми, крім живлення та іншого.

Навіть включення деяких ненавмисно несправних з'єднань, можливо, не перерве це: якщо ви прив’яжете всі гпіоси до силової рейки, встановивши їх як вихід (до протилежної силової шини), що може розсіювати досить багато енергії. Шпилька gpio, ймовірно, захищена від короткого замикання, і так нічого шкідливого не станеться.

Проектування зовнішньої схеми, що знищує мікросхему за бажанням, на мою думку, теж не банально. Перше, що спадає на думку, потребує джерела живлення високої напруги, нмосу та резистора:

^{імітувати цю схему - Схематично створено за допомогою CircuitLab} Де:

• - звичайне джерело живлення для мікрофонів, якесь від 3v3 до 5V або все, що потрібно$V_{CC}$
• НВ - це джерело живлення, напруга якого значно перевищує абсолютні максимальні показники мікро
• D1 є для захисту вашого цінного джерела напруги 3V3
• R1 піднімає ворота MOSFET високо, коли мікро не тримає його на землі
• М1 - призначений вбивця

операція проста: якщо мікровипуск GPIOx M1 включається, Vcc піднімається, і ваш чіп загоряється. Зауважте, що це шалене налаштування, наприклад, HV потрібно включити після того, як ви впевнені, що GPIOx міцно тримається за землю. Деяким транзисторам, можливо, не сподобаються якісь -5В Vgs і так далі ... Але ви отримаєте малюнок.

Відмова: supercat сказав це першим у коментарі.

Власне, більшість MCU неможливо фізично знищити, але їх можна надягати достатньо, щоб почати несправність до тієї точки, в якій він непридатний. У мене є досвід роботи з TSP MSP430, тож ось що:

Ці MCU дозволяють перепрограмувати весь спалах у будь-який час. Знову спалаху можна не тільки переписати мільйони разів, поки не вийде з ладу, але і генератор програмування спалаху на мікросхемі може спричинити збій у нижньому кінці процесора, якщо генератор програмування неправильно налаштований. Це допустимий діапазон частот, дозволений для програмування. Якщо виходити за межі цього діапазону (повільніше), час програмування може стати надмірно довгим і спричинити збій флеш-комірок. Пройшовши лише кілька сотень циклів, можна «спалити» спалахи, спричинивши постійний збій.

Також деякі моделі дозволяють розігнати серцевину так, щоб вона зростала до більшої швидкості за рахунок збільшення внутрішньої напруги. Блок живлення працює від напруги напруги 1,8-3,6 В, але сам сердечник розроблений для роботи на рівні 1,8 В. Якщо ви розігнали занадто багато ядра на силовій рейці 3,6 В, перемикаючи всі введення-виведення, активуючи всі периферійні пристрої та працюючи на палаючих 40 МГц (звичайно, макс. серцевина через перегрів. Насправді деякі хлопці сказали, що вони досягли цих частот (зазвичай DCO виходить з ладу раніше і чіп зберігається, але добре ... можливо).

Просто спробувати?

За словами stackexchange - "Це дійсно погана ідея залишати вхідний штифт MCU плаваючим?"

Він описує кілька обставин, за яких мікросхему може пошкодити штифт відкритого ланцюга. Редагувати: приклад продуктів Spansion Analog and Microcontroller Products :

4.1 Портовий вхід / невикористані цифрові вводи
/ виводи PIN-кодів Настійно рекомендується не залишати цифрові штифти вводу-виводу без з'єднання, поки вони перемикаються на вхід. У цьому випадку ці штифти можуть перейти у так званий плаваючий стан. Це може спричинити високий струм ICC, що несприятливо для режимів низької потужності. Також може статися пошкодження MCU.

Умовою у цьому питанні є саме шпильки відкритого кола.

Таким чином, наше завдання полягає в тому, щоб керувати , що з травня в буде пошкодити штифт. Я вважаю, що цього достатньо, щоб вийти за рамки "перешкод".

Один з механізмів, визначений у цій відповіді, - це введення вхідного штифта до напруги середнього значення, де два допоміжних транзистора обидва є "включеним". Працюючи в такому режимі, контактний інтерфейс може нагрітися або вийти з ладу.

Вхідний штифт має дуже високий опір, а також є конденсатором. Імовірно, їх достатньо з'єднання між сусідніми штифтами, що перемикання сусідніх штифтів може досить швидко загнати заряд на вхідний штифт і підштовхнути його до цього «гарячого» стану. Чи може половина штифтів вводу / виводу, що приводяться в цей стан, нагріти мікросхему достатньо, щоб завдати шкоди?

(Чи існує режим, коли ємність відкритого штифта може використовуватися як подвійник напруги? Хм.)

Я також думаю, що пошкодження спалаху достатньо. Я думаю, що це досить погано, щоб зробити чіп марним.

Це не потрібно, щоб це було всім спалахом, а лише сторінка, яка містить вектори включення, RESET тощо. Обмеження на одній сторінці може зайняти кілька десятків секунд.

Я мав вказівку, але не має надійних доказів), що для деяких MCU це може бути гірше. Я відвідав презентацію пару років тому. Хтось запитав, чому конкуренти пропонують деталі зі значно більшими флеш-циклами. (Великий неназваний виробник MCU) ведучий заявив, що вони застосували набагато більш консервативний підхід у своїх специфікаціях для флеш-пам’яті. Він сказав, що їх гарантія була визначена при значно більш високій температурі, ніж це було промисловою нормою. Хтось запитав "так що". Доповідач зазначає, що у кількох виробників вироби будуть значно менші терміни перезапису, ніж їх частини при тих же темпах, що і раніше. Мій спогад у 5 разів стане <1x. Він сказав, що це дуже нелінійно. Я вважав, що це означає, що програмування на 80С замість 25С було б "поганою справою".

Отже, перезапис флеш-пам’яті у поєднанні з дуже гарячим чіпом може також зробити його марним менше ніж за 10 секунд.

Редагувати:
Я вважаю, що «звільнити синій дим від смерті» - важче обмеження, ніж потрібно. Якщо будь-яка з: контактна схема RESET, детектор коричневого виходу, схема включення живлення, RC або кристалічний генератор (і, можливо, кілька інших ланцюгів) можуть бути пошкоджені, мікросхема буде непридатною.

Як зазначали інші, розбиття спалаху також вбило б його непоправно.

"Дим" звучить вражаюче, але менш очевидні смертельні напади все ще є смертельними, і набагато складніше їх виявити.

Одним з потенційних джерел такого руйнування є замикання SCR, де ненавмисні (внутрішні) транзистори в мікросхемі збираються разом, щоб утворити своєрідний TRIAC, який потім може потонути багато струму. Це може легко продути з'єднувальні дроти, і я навіть бачив пристрої з пластмасовими корпусами, помітно викривленими через тепла.

Типовою причиною є введення (навіть на мить) введення вище або нижче рейки подачі або наземного відповідно, але я думаю, ви могли б побачити це, якщо вхід залишився плаваючим. І тоді не важко уявити схему, де плаваюча вхідність контролюється програмним забезпеченням (хоча це було б дуже дурною справою).

МОЖЛИВО, що програмне забезпечення, навмисно написане для цілей, орієнтованого на дуже конкретний процесор, може бути в змозі змусити розгону до точки, в якій процесор перегріється. За умови, звичайно, що процесор містить програмно-налаштовані регістри управління тактовою системою.

Звичайно, НЕ можливо, що ВСІ процесори можуть бути пошкоджені таким чином. Якби це було правдою, у нас були мільярди Z80s і 6800s та 6502s, які були прокладені в сторону незрозумілими тировими написами програмного забезпечення назад, коли ми ще вводили машинний код вручну, роблячи безліч випадкових помилок.

Це моя запис про зруйнування мікроконтролера з якомога менше деталей ...

Просто перемкніть вихідні штифти на кілька кГц!

Ви все одно можете не бачити диму, хоча це залежить від внутрішнього режиму відмови.

^{імітувати цю схему - Схематично створено за допомогою CircuitLab}

- редагувати, додано 22 серпня--

Тепер я не думаю, що ви можете зіпсувати мікроконтролер за вказаними критеріями. Але ви можете ЛЕГКО зіпсувати зовнішню схему з неправильним кодом. Приклад, який спадає на думку, - це простий перетворювач прискорення, який я нещодавно розробив ... просто призупинення коду під час налагодження могло коротко встановити індуктор на землю через MOSFET. POOF

З точки зору звичайного коду в режимі користувача, я не думаю, що ви можете написати щось, що порушить чіп.

Однак я пам’ятаю дні мікропроцесорів, які могли бути знищені менше ніж за хвилину чи навіть секунди, якби тепловідвід відпав. Потім вони додали схеми термічного детектування, які б відключили годинник, якщо деталь нагрілася. Тепер, коли ми можемо поставити набагато більше транзисторів, ніж можна використати одразу, мікросхеми здатні виробляти більше тепла, ніж тепловідвід може розсіюватися, а його керування живленням та теплові ланцюги, які захищають його. Наприклад, див. Intel Turbo Boost 2.0. Тому здається, що цілком можливо розплавити мікросхему, якщо ви зможете обійти або підвищити ліміт управління живленням і тепловим контуром. Отже, якщо вони знаходяться під контролем програмного забезпечення (не маю ідеї; можливо, це потребує оновлення BIOS?), Тоді ви можете запустити купу паралельних циклів "нічого не робити" разом з інтегрованою роботою GPU, а також апаратним декодуванням і кодуванням H.264, і все, що може зробити чіп, все відразу, поки чіп не перегріється і не викине чарівний синій дим.

Я найбільше знайомий з процесорами STM32, тому вони найбільше стосуються цієї родини. Але подібний підхід можливий і для інших процесорів:

1. Існує постійний режим захисту від запису. Тож якщо ви програмуєте цей біт та якусь непотрібну програму на FLASH, MCU більше ніколи не можна використовувати. Я не знаю, чи вважається це «стримуючим», але воно передбачає постійний апаратний механізм.

2. Шпильки програмування можна налаштувати як GPIO. Оскільки годинниковий штифт керується пристроєм програмування, це може бути використане для спричинення короткого замикання. Швидше за все, він би зламав той єдиний штифт, який, будучи шпилькою програмування, був би дуже поганим.

3. Як і згадував dirkt, PLL можна використовувати для розгону процесора. Це може призвести до його перегрівання або пошкодження іншим способом.

Хто коли-небудь говорив, що це не розуміє, наскільки процес проектування таких чіпів. Це не означає, що проскакування не відбувається і те, що висвітлення регресії та кутових випадків кодом іноді пропускає речі, але заявляти, що ВСІ чи навіть більшість процесорів мають цей недолік, є логічно сумнівним.

Просто запитайте себе, що відбувається, коли перекриття шафи перевищує вимоги до часу (якщо припустити, що він не перегрівається). чіп виходить з ладу і, можливо, пошкоджує пам'ять і навіть доступ до жорсткого диска, але принципово процесор знову запустить резервну копію і навіть запустить ОС знову, якщо пошкодження буде виправлено. То який же правильно розроблений мікрокод може спричинити БОЛЬШЕ порушення, ніж цей сценарій? - відповідь, швидше за все, ніхто.

TLDR; У всіх процесорах є така помилка - НЕ

Я вважаю, що, звичайно, можливо фізично знищити мікроконтролер (MC) за допомогою програмного забезпечення. Все, що потрібно, - це комбінація МС для виконання "щільного" циклу інструкцій, що спричиняє 100% використання, та "несправного" радіатора, який дозволяє накопичувати тепло всередині мікросхеми. Від того, чи буде відмова тривати секунди, хвилини чи години, буде залежати від того, наскільки швидко накопичується тепло.

У мене портативний комп'ютер, яким я можу користуватися ним лише на 50% безперервного використання. Якщо я перевищую це, комп'ютер вимикається. Це означає, що при 50% використанні температура MC нижче встановленої тригерної точки. Зі збільшенням використання температура MC збільшується до досягнення тригерної точки. Якщо ланцюг термічного вимикання не працював (або не мав), температура МС продовжуватиме зростати, поки вона не зруйнується.

^{імітувати цю схему - Схематично створено за допомогою CircuitLab}

#include <avr/io.h>

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

Код, наведений вище, змушує MCU підштовхувати PB2 високо, а PB4 низько витягувати, і це створює коротке замикання від VDD до PB2 до PB4 до GND і швидко драйвери портів PB2 та / або PB4 будуть смажитися. Коротке замикання може бути невинною помилкою, як випадковий паяльний міст.