Cara Mengatasi ESP32 Brownout Detector Was Triggered dan Guru Meditation

Pesan ESP32 brownout detector was triggered berarti tegangan suplai board sempat turun sekejap di bawah batas aman, lalu chip me-restart dirinya sendiri demi keamanan. Masalahnya hampir tidak pernah ada di kodemu, melainkan di sisi daya: port USB yang lemah, kabel yang tipis dan panjang, regulator yang terlalu kecil, atau servo dan LED strip yang mengambil daya dari jalur yang sama dengan ESP32. Penyebab besar kedua ESP32 terus restart adalah crash perangkat lunak; dalam kasus ini Serial Monitor menampilkan baris seperti Guru Meditation Error, task_wdt, atau Stack canary.

Kabar baiknya: ESP32 sendiri memberi tahu kenapa ia restart, asalkan kamu tahu cara membaca pesannya. Di panduan ini kamu akan lebih dulu belajar mengenali kode rst di baris boot dan pesan-pesan error, lalu mengatasi brownout untuk selamanya dengan catu daya, kabel, dan kapasitor yang tepat. Setelah itu kita bahas error Guru Meditation seperti LoadProhibited dan StoreProhibited, stack overflow, null pointer, dan timeout watchdog, dan kamu akan melacak crash sampai ke baris kode yang tepat dengan ESP Exception Decoder. Terakhir, kita lihat pin strapping (GPIO0, 2, 12, dan 15) yang bisa merusak proses boot.

Kenapa ESP32 terus restart? Baca pesannya dulu

Sebelum mulai mencari masalah, buka Serial Monitor di 115200 baud dan tekan tombol EN di board. Di setiap boot, bootloader ROM di dalam ESP32 lebih dulu mencetak baris tanggal seperti “ets Jun 8 2016 00:22:57”, lalu baris seperti rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT). Bagian rst memberi tahu kenapa board restart, bagian boot menunjukkan mode yang dipakai ketika board menyala. Kalau board terjebak dalam loop, kamu akan menemukan pesan error, yaitu “kata-kata terakhir” dari eksekusi sebelumnya, tepat di atas baris-baris ini. Tabel di bawah merangkum pesan yang akan kamu lihat dan dari mana harus mulai:

Apa itu “Brownout detector was triggered” dan kenapa terjadi?

Brownout adalah penurunan tegangan singkat tanpa daya benar-benar hilang. ESP32 punya brownout detector yang terus mengawasi jalur suplai, dan di core Arduino ambangnya disetel ke level terendah, sekitar 2,43 V. Begitu tegangan turun di bawah nilai ini, chip melindungi radio dan memori flash, mencetak “Brownout detector was triggered” ke Serial Monitor, lalu me-restart dirinya sendiri. Alasannya sederhana: pada tegangan rendah, flash bisa salah dibaca, data yang tersimpan bisa rusak, dan CPU bisa menjalankan instruksi acak. Detector ini membuat board melakukan reset yang bersih alih-alih berperilaku tak terduga. Modul ESP32-WROOM-32 dirancang untuk bekerja di antara 3,0 dan 3,6 V, jadi ketika jalur suplai mencapai 2,43 V, kondisinya sudah jauh di luar zona aman.

Setelah pesan brownout, baris boot menampilkan rst:0xc (SW_CPU_RESET) atau rst:0x3 (SW_RESET), tergantung versi core Arduino-mu, karena interrupt milik detector mencetak pesan lalu me-restart chip lewat perangkat lunak. Jangan sampai ini menyesatkanmu: kode yang sama mencatat di memori chip bahwa penyebabnya brownout, dan esp_reset_reason() mengembalikan ESP_RST_BROWNOUT. Kalau yang bekerja adalah reset brownout milik hardware sendiri, barisnya justru berbunyi rst:0xf (RTCWDT_BROWN_OUT_RESET). Di core 3.x, yang berbasis ESP-IDF 5, baris ini menjadi log level info (I BOD: Brownout detector was triggered). Karena library Arduino yang sudah dikompilasi hanya mencetak log level error, pesan ini biasanya tidak muncul sama sekali dan board restart diam-diam; kalau kamu melihat rst:0x3 atau rst:0xc yang tidak jelas penyebabnya ketika boot, cek alasan reset dengan sketch diagnostik di bawah. Untuk memahami kenapa tegangan turun, lihat berapa besar arus yang ditarik ESP32:

Selisih di tabel ini adalah inti masalah brownout: sampai kodemu menyalakan Wi-Fi, board hanya menarik sekitar 50 mA ketika diam, tapi di baris WiFi.begin() arusnya melonjak lima sampai enam kali lipat dalam beberapa mikrodetik. Kalau catu daya, kabel, dan regulator tidak bisa mengikuti permintaan mendadak itu, tegangannya ambruk. Karena itulah Espressif menyarankan catu daya yang mampu memberi minimal 500 mA untuk ESP32. Gejalanya sangat familiar: board menyala, mencetak beberapa baris ke Serial Monitor, reset begitu Wi-Fi atau Bluetooth mulai, dan ini berubah menjadi loop tanpa akhir. Hal yang sama bisa terjadi ketika servo bergerak, relay berpindah, atau LED strip menyala putih.

Penyebab brownout yang paling umum

• Kabel USB yang tipis atau panjang: kabel daya tipis di kabel murah bisa menambah hambatan sampai 0,5 Ω untuk jalur pergi-pulang. Menurut hukum Ohm, lonjakan 400 mA kehilangan 0,2 V di kabel seperti itu.
• Port USB atau hub yang lemah: port di keyboard dan monitor, hub tanpa adaptor daya, dan port depan beberapa laptop membiarkan tegangan turun ketika arus puncak.
• Dropout regulator: AMS1117 yang ada di sebagian besar board butuh selisih 1,0–1,3 V antara input dan output-nya. Kalau tegangan di pin 5V turun di bawah kira-kira 4,3 V, output-nya tidak bisa bertahan di 3,3 V.
• Menyambung baterai langsung: menghubungkan sel Li-ion 3,7 V ke pin 5V menurunkan output di bawah 3 V karena dropout regulator; dua baterai AA cepat turun di bawah tegangan minimum ESP32 ketika diberi beban.
• Pin 3.3V Arduino Uno: pin ini hanya disarankan untuk sekitar 50 mA; jauh dari cukup untuk ESP32 dengan Wi-Fi menyala.
• Beban di jalur yang sama: kalau servo, relay, buzzer, motor DC, atau strip WS2812B memakai 5 V yang sama dengan ESP32, setiap gerakan menarik tegangan turun.
• Breadboard dan kabel jumper: kontak yang longgar dan jumper yang tipis menambah sedikit hambatan di setiap sambungan; mengalirkan daya lewat breadboard membuat keadaan makin buruk.
• ESP32-CAM: ketika kamera, Wi-Fi, dan LED flash bekerja bersamaan, arusnya jadi sangat tinggi; board ini suka 5 V dan minimal 2 A. Lihat panduan ESP32-CAM untuk detailnya.

Solusi 1: perbaiki catu daya dan kabel

Langkah pertama dan paling efektif adalah suplai yang lebih kuat. Hubungkan board dengan kabel data yang pendek, tebal, dan terbukti bagus, langsung ke port USB di belakang komputer atau ke adaptor 5 V dengan rating minimal 1 A. Port USB 2.0 dirancang untuk memberi 500 mA dan port USB 3.0 900 mA; 500 mA yang disarankan Espressif tepat berada di batas port USB 2.0, jadi begitu rugi-rugi kabel ditambahkan, masalah pun mulai. Kalau mengganti kabel saja sudah menghilangkan error, kemungkinan besar hambatan kabel itulah biangnya. Kamu bisa menghitung berapa tegangan yang hilang di kabel dengan V = I × R memakai alat kalkulator hukum Ohm.

Proyek bertenaga baterai butuh perhatian ekstra. Sel Li-ion seperti 18650 memberi 4,2 V ketika penuh dan sekitar 3,0 V ketika kosong. Rentang ini tidak cocok untuk sambungan langsung ke pin 3V3 (4,2 V melewati batas 3,6 V), juga tidak cocok untuk pin 5V dengan AMS1117-nya. Solusi yang benar adalah memberi daya dari sel lewat modul boost 5 V ke pin 5V, atau menyuplai jalur 3V3 langsung lewat regulator low-dropout dengan rating minimal 500 mA (misalnya ME6211 atau HT7833) plus sebuah kapasitor. Kamu bisa memperkirakan berapa lama proyekmu bertahan dengan baterai memakai alat kalkulator umur baterai, dan mempelajari rangkaian pengisian di panduan modul charger TP4056.

Solusi 2: tambahkan kapasitor di antara 3V3 dan GND

Kapasitor bekerja seperti tandon kecil yang menyuplai energi sendiri ketika ada lonjakan arus, sampai regulator dan kabel bisa menyusul. Tambahkan kapasitor elektrolit 100–470 µF di antara pin 3V3 dan GND board, sedekat mungkin dengan board, plus kapasitor keramik 100 nF di sebelahnya. Kapasitor elektrolit menangani penurunan selama milidetik, yang keramik menangani riak berfrekuensi tinggi yang sangat singkat. Efeknya bisa kamu lihat kasar dengan ΔV = I × Δt / C: bahkan kalau kapasitor 470 µF sendirian menyuplai tambahan 200 mA selama 200 µs, tegangan hanya turun 0,085 V. Tanda 104 di kapasitor keramik berarti 100 nF; tanda lain bisa kamu baca dengan alat kode kapasitor.

Solusi 3: beri daya terpisah untuk servo, motor, dan LED strip

Walaupun ESP32 sendiri sudah mendapat daya dengan benar, beban di jalur yang sama bisa menarik tegangan turun. Bahkan servo kecil seperti SG90 menarik beberapa ratus mA ketika mulai bergerak; satu LED WS2812B memakai sekitar 60 mA ketika putih penuh, jadi strip 30 LED bisa mencapai 1,8 A. Beri daya beban ini bukan dari pin 5V atau 3V3 ESP32, tapi dari suplai 5 V terpisah; misalnya, kamu bisa menurunkan adaptor 12 V ke 5 V dengan modul buck LM2596. Aturan terpentingnya adalah menyambungkan GND kedua suplai; tanpa ground bersama, jalur sinyal tidak punya referensi dan servo atau strip berperilaku acak. Kami membahasnya secara detail di Kenapa Arduino-ku terus reset? dan Ground Bersama (GND).

Apakah mematikan brownout detector itu solusi?

“Solusi” paling umum di internet adalah mematikan detector dengan satu baris. Kode di bawah menonaktifkan detector dengan mengosongkan register brownout ESP32, dan pesan error-nya hilang. Tapi penurunan tegangannya tetap terjadi; hanya saja tidak ada lagi yang memperingatkanmu. Pakai kode ini hanya untuk diagnosis: kalau board berjalan normal dengan detector mati, kamu sudah memastikan bahwa masalahnya pasti di catu daya. Setelah itu hapus barisnya dan perbaiki suplainya.

1#include "soc/soc.h"
2#include "soc/rtc_cntl_reg.h"
3
4void setup() {
5  // YALNIZ TEŞHİS İÇİN: brownout dedektörünü kapat / DIAGNOSIS ONLY: disable the brownout detector
6  WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0);
7
8  Serial.begin(115200);
9  Serial.println("Brownout dedektoru kapali / brownout detector disabled");
10}
11
12void loop() {
13}

Kode penyebab rst: ESP32 memberi tahu kenapa ia restart

Nilai rst: yang dicetak ROM di setiap boot menunjukkan bagaimana eksekusi sebelumnya berakhir. Pada boot normal, nilai boot-nya 0x13 (SPI_FAST_FLASH_BOOT), artinya board menjalankan programnya dari flash. Tabel di bawah mendaftar kode yang paling sering akan kamu lihat. Kode ROM tidak selalu cukup sendirian: ESP.restart() dan restart setelah Guru Meditation sama-sama muncul sebagai 0xc, sedangkan brownout muncul sebagai 0xc atau 0x3 tergantung versi core. Untuk membedakannya, pakai sketch esp_reset_reason() di bagian berikutnya.

Sketch diagnostik: cetak alasan reset, memori, dan stack

Upload kode di bawah sebagai sketch terpisah, atau tambahkan baris-barisnya ke setup() dan loop() proyekmu yang bermasalah. Setiap kali board menyala, ia mencetak alasan reset dalam teks yang mudah dibaca, sudah berapa kali ia boot, dan status memori ke Serial Monitor. Penghitung yang ditandai RTC_DATA_ATTR tinggal di memori RTC, jadi ia bertahan melewati reset perangkat lunak dan deep sleep, dan hanya terhapus ketika daya benar-benar dicabut. Kalau penghitungnya naik setiap beberapa detik, kamu langsung tahu bahwa board terjebak dalam loop reset.

1#include <esp_system.h>
2
3RTC_DATA_ATTR uint32_t bootCount = 0;   // yazılım resetinde korunur / survives software resets
4
5// Reset nedenini okunabilir yazıya çevir / turn the reset reason into readable text
6const char* reasonText(esp_reset_reason_t r) {
7  switch (r) {
8    case ESP_RST_POWERON:   return "POWERON: guc acilisi ya da EN / power-on or EN button";
9    case ESP_RST_SW:        return "SW: ESP.restart()";
10    case ESP_RST_PANIC:     return "PANIC: Guru Meditation";
11    case ESP_RST_INT_WDT:   return "INT_WDT: kesme watchdog'u / interrupt watchdog";
12    case ESP_RST_TASK_WDT:  return "TASK_WDT: gorev watchdog'u / task watchdog";
13    case ESP_RST_WDT:       return "WDT: diger watchdog / other watchdog";
14    case ESP_RST_DEEPSLEEP: return "DEEPSLEEP: derin uykudan uyanma / deep sleep wake-up";
15    case ESP_RST_BROWNOUT:  return "BROWNOUT: gerilim dusmesi / supply voltage dropped";
16    default:                return "UNKNOWN: bilinmiyor / unknown";
17  }
18}
19
20void setup() {
21  Serial.begin(115200);
22  delay(1000);                          // Seri Monitör'ün açılmasını bekle / wait for the Serial Monitor
23  bootCount++;
24  Serial.printf("Acilis sayisi / boot count: %u\n", (unsigned)bootCount);
25  Serial.printf("Reset nedeni / reset reason: %s\n", reasonText(esp_reset_reason()));
26}
27
28void loop() {
29  // Bellek durumu / memory status
30  Serial.printf("Bos heap / free heap: %u B, en dusuk / minimum: %u B, en buyuk blok / largest block: %u B\n",
31                (unsigned)ESP.getFreeHeap(), (unsigned)ESP.getMinFreeHeap(), (unsigned)ESP.getMaxAllocHeap());
32  // loopTask yığınında hiç kullanılmamış en küçük alan / smallest unused space on the loopTask stack
33  Serial.printf("loopTask bos yigin / free stack: %u B\n", (unsigned)uxTaskGetStackHighWaterMark(NULL));
34  delay(5000);
35}

Nilai yang dicetak di loop juga membongkar masalah yang diam-diam. Kalau free heap turun sedikit di setiap putaran, programmu mengalami memory leak dan cepat atau lambat board akan crash. Kalau blok terbesar jauh lebih kecil daripada free heap, memorinya terfragmentasi; ini biasanya berasal dari objek String yang terus membesar dan mengecil di dalam loop. Kalau sisa stack loopTask turun di bawah beberapa ratus byte, stack overflow sudah di depan mata. Kalau alasan reset-nya BROWNOUT, fokuslah ke bagian tentang daya; kalau PANIC, TASK_WDT, atau INT_WDT, fokuslah ke bagian perangkat lunak di bawah.

Apa itu Guru Meditation Error? Baca output crash baris demi baris

Guru Meditation Error adalah laporan crash yang dicetak panic handler ketika CPU ESP32 menemui error yang tidak bisa dipulihkan; namanya berasal dari layar error komputer Amiga zaman dulu. Laporannya terlihat menakutkan pada awalnya, tapi hanya beberapa baris yang penting. Core 1 memberi tahu di core mana error terjadi: di Arduino, setup() dan loop() berjalan di core 1, sedangkan stack Wi-Fi berjalan di core 0. Nama di dalam kurung adalah jenis exception-nya. Ketika laporan selesai, board mencetak “Rebooting...” lalu restart; kamu akan melihat rst:0xc di baris boot.

LoadProhibited, StoreProhibited, dan jenis exception lainnya

Yang paling umum dari error ini adalah memakai null pointer. NULL adalah alamat 0, dan di ESP32 tidak ada memori yang bisa dibaca di sekitar alamat 0, jadi membaca dari tempat yang ditunjuk pointer kosong menghasilkan LoadProhibited, dan menulis ke sana menghasilkan StoreProhibited. Di kasus ini EXCVADDR adalah petunjuk yang sempurna: 0x00000000 menunjuk ke pointer itu sendiri, sedangkan nilai kecil seperti 0x00000004 atau 0x00000010 menunjuk ke sebuah field di dalam pointer kosong (NULL ditambah offset field itu). Di proyek Arduino, penyebab paling umum adalah fungsi yang mengembalikan NULL untuk berarti “tidak ditemukan”, lalu nilai itu dipakai tanpa dicek. Di contoh di bawah, strstr() mengembalikan NULL kalau tidak menemukan teksnya; tanpa pengecekan, board crash dengan EXCVADDR 0x00000005.

1const char* response = "temp=23.5;hum=40";   // sunucudan gelen yanıt / reply from a server
2
3void setup() {
4  Serial.begin(115200);
5  delay(500);
6
7  // YANLIŞ: "pres=" yoksa strstr NULL döner ve kart çöker (EXCVADDR 0x00000005)
8  // WRONG: if "pres=" is missing strstr returns NULL and the board crashes (EXCVADDR 0x00000005)
9  // float pressure = atof(strstr(response, "pres=") + 5);
10
11  // DOĞRU: işaretçiyi kullanmadan önce NULL kontrolü yap / RIGHT: check for NULL before using the pointer
12  const char* found = strstr(response, "pres=");
13  if (found != nullptr) {
14    float pressure = atof(found + 5);
15    Serial.println(pressure);
16  } else {
17    Serial.println("pres alani bulunamadi / pres field not found");
18  }
19}
20
21void loop() {
22}

Stack overflow: error “Stack canary watchpoint triggered”

Di ESP32 setiap task punya stack berukuran tetap, tempat variabel lokal, pemanggilan fungsi, dan alamat kembali disimpan. Di Arduino, loopTask yang menjalankan setup() dan loop() punya stack 8192 byte. Mendeklarasikan array lokal 10.000 byte di dalam loop(), fungsi yang memanggil dirinya sendiri (rekursi), atau fungsi library dengan banyak variabel lokal akan melewati batas ini. Di ujung stack ada area penjaga (canary); ketika stack mencapainya, board mencetak Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception) dan tepat di bawahnya Debug exception reason: Stack canary watchpoint triggered (loopTask). Nama di dalam kurung adalah task yang stack-nya meluap. Masalah yang sama kadang muncul sebagai ***ERROR*** A stack overflow in task loopTask has been detected. Begini cara mengatasinya:

• Pindahkan array besar keluar dari stack: deklarasikan array secara global atau tambahkan static di depannya; dengan begitu ia tinggal di RAM permanen, bukan di stack.
• Perbesar stack loopTask: taruh SET_LOOP_TASK_STACK_SIZE(16 * 1024); di bagian atas sketch-mu untuk menaikkan stack loop() ke 16 KB.
• Beri task-mu sendiri ruang yang cukup: di ESP32, ukuran stack yang diberikan ke xTaskCreate dan xTaskCreatePinnedToCore dalam satuan byte, bukan word seperti di FreeRTOS pada platform lain. 1024 byte terlalu kecil bahkan untuk task yang memakai Serial.printf; mulailah dengan 4096.
• Ukur: uxTaskGetStackHighWaterMark(NULL) mengembalikan, dalam byte, jumlah stack terkecil yang belum pernah dipakai task sejauh ini; kalau turun di bawah beberapa ratus byte, perbesar stack-nya.
• Hindari rekursi: ubah fungsi yang memanggil dirinya sendiri menjadi perulangan atau batasi kedalamannya.

Task watchdog: error “task_wdt: Task watchdog got triggered”

Watchdog adalah timer yang menyadari program yang macet lalu menyelamatkan board. Task Watchdog (Task WDT) milik ESP32 mengharapkan task yang terdaftar padanya memberi sinyal “aku masih hidup” secara berkala. Di core Arduino, secara default ia mengawasi task idle (IDLE) milik core 0, dengan timeout 5 detik. Kalau task yang berjalan di core 0 tidak melepas CPU selama 5 detik, task IDLE tidak bisa berjalan dan Serial Monitor menampilkan pesan yang diawali E (10257) task_wdt: Task watchdog got triggered. Setelahnya ada daftar task yang tidak me-reset watchdog tepat waktu (biasanya - IDLE (CPU 0)) dan, di bawah Tasks currently running:, task yang sedang berjalan pada momen itu. Di core Arduino ini memicu panic dengan baris task_wdt: Aborting. dan board restart.

Penyebab paling umum: loop yang dipasang di core 0 dengan xTaskCreatePinnedToCore yang tidak pernah memanggil vTaskDelay(), perulangan while yang menunggu balasan sensor tanpa timeout, atau delay() dan operasi panjang di dalam callback library seperti AsyncWebServer. Pada kasus terakhir kamu akan melihat task async_tcp di daftar, bukan IDLE. Solusinya adalah memecah pekerjaan panjang menjadi potongan kecil dan menambahkan jeda singkat seperti vTaskDelay(1) di loop-mu. Fungsi loop() sendiri tidak diawasi secara default; kalau mau, panggil enableLoopWDT() di setup() supaya board juga restart ketika loop() macet lebih dari 5 detik. Mematikan watchdog dengan disableCore0WDT() menyembunyikan error-nya tapi tidak memperbaiki kode yang macet. Untuk lebih lanjut tentang task dan core, lihat FreeRTOS dan dua inti ESP32. Kode di bawah menunjukkan struktur task yang benar sekaligus langkah pencegahan stack overflow:

1SET_LOOP_TASK_STACK_SIZE(16 * 1024);   // loop() yığını 8 KB yerine 16 KB / loop() stack 16 KB instead of 8 KB
2
3volatile uint32_t sampleCount = 0;
4
5// 0. çekirdekte çalışan görev / task running on core 0
6void sensorTask(void* parameter) {
7  for (;;) {
8    sampleCount = sampleCount + 1;       // sensörünü burada oku / read your sensor here
9    vTaskDelay(pdMS_TO_TICKS(10));       // IDLE görevine sıra ver, task_wdt tetiklenmez / let IDLE run, no task_wdt
10  }
11}
12
13void setup() {
14  Serial.begin(115200);
15  // Yığın boyutu bayt cinsindendir: 4096 bayt / stack size is in bytes: 4096 bytes
16  xTaskCreatePinnedToCore(sensorTask, "sensorTask", 4096, NULL, 1, NULL, 0);
17}
18
19void loop() {
20  static uint8_t buffer[10000];          // static: yığında değil kalıcı RAM'de / static: in RAM, not on the stack
21  memset(buffer, 0, sizeof(buffer));
22
23  Serial.printf("Ornek / samples: %u, loopTask bos yigin / free stack: %u B\n",
24                (unsigned)sampleCount, (unsigned)uxTaskGetStackHighWaterMark(NULL));
25  delay(1000);
26}

Interrupt wdt timeout dan IRAM_ATTR: crash di dalam interrupt

Interrupt Watchdog (Interrupt WDT) jauh lebih tidak sabar: kalau handler interrupt (ISR) atau bagian kode dengan interrupt dimatikan berjalan lebih dari 300 ms, board crash dengan Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1). Memakai Serial.print, delay(), I2C, atau Wi-Fi di dalam ISR adalah penyebab paling umum. Memori flash adalah jebakan lain: ketika Preferences, EEPROM, atau LittleFS menulis ke flash, cache flash dimatikan sejenak. Kalau ada interrupt datang di waktu itu dan handler-nya tinggal di flash, board melaporkan Cache disabled but cached memory region accessed. Solusinya adalah menandai ISR dengan IRAM_ATTR supaya tinggal di RAM, dan di dalamnya hanya menyetel flag; pekerjaan sebenarnya dilakukan loop(). Variabel yang dipakai bersama oleh ISR dan loop() harus volatile.

1const int BUTTON_PIN = 27;              // buton GPIO 27 ile GND arasında / button between GPIO 27 and GND
2volatile bool buttonPressed = false;    // ISR ile loop arasında paylaşılan bayrak / flag shared by the ISR and loop
3uint32_t pressCount = 0;
4
5void IRAM_ATTR onButton() {             // IRAM_ATTR: fonksiyon flaşta değil RAM'de durur / the function lives in RAM, not flash
6  buttonPressed = true;                 // yalnızca bayrak kaldır, Serial yok / only set a flag, no Serial
7}
8
9void setup() {
10  Serial.begin(115200);
11  pinMode(BUTTON_PIN, INPUT_PULLUP);
12  attachInterrupt(digitalPinToInterrupt(BUTTON_PIN), onButton, FALLING);
13}
14
15void loop() {
16  if (buttonPressed) {
17    buttonPressed = false;
18    pressCount++;
19    Serial.printf("Butona basildi / button pressed: %u\n", (unsigned)pressCount);   // yavaş iş burada / slow work here
20  }
21}

Mengubah Backtrace menjadi baris kode dengan ESP Exception Decoder

Alamat di baris Backtrace tidak memberi tahu apa-apa sendirian; alat yang mengubahnya menjadi file, fungsi, dan nomor baris di kode sumbermu bernama ESP Exception Decoder. Di Arduino IDE 1.8 yang lama, ini adalah plugin yang ditambahkan ke menu Tools. Di Arduino IDE 2 kamu memakai ekstensi buatan komunitas dengan nama yang sama:

1. Unduh file .vsix dari bagian Releases proyek dankeboy36/esp-exception-decoder di GitHub. Untuk Arduino IDE 2, pilih rilis 1.x; rilis 2.x yang lebih baru dibuat untuk VS Code.
2. Tutup Arduino IDE dan salin file-nya ke %UserProfile%\.arduinoIDE\plugins di Windows atau ~/.arduinoIDE/plugins di macOS dan Linux; buat folder-nya kalau belum ada.
3. Buka IDE, buka sketch yang crash, kompilasi dengan Verify, lalu upload ke board.
4. Buka Serial Monitor dan tunggu sampai crash terjadi lagi.
5. Buka command palette dengan Ctrl+Shift+P (Cmd+Shift+P di macOS) dan jalankan ESP Exception Decoder: Show Decoder Terminal.
6. Salin blok Guru Meditation dari Serial Monitor, termasuk baris Backtrace, lalu tempel ke terminal yang terbuka; alat ini menampilkan setiap alamat beserta nama file, fungsi, dan nomor barisnya.

Kalau kamu tidak bisa menginstal ekstensinya, pekerjaan yang sama bisa dilakukan secara manual. Menu Sketch > Export Compiled Binary meninggalkan file berekstensi .elf di folder build di dalam folder sketch-mu. Perintah xtensa-esp32-elf-addr2line -pfiaC -e sketch.ino.elf 0x400d1a29 0x400d0f6e dari toolchain ESP32 mengubah alamat-alamat ini menjadi nama fungsi dan nomor baris. Kalau kamu memakai PlatformIO, cukup tambahkan baris monitor_filters = esp32_exception_decoder ke platformio.ini; output crash lalu otomatis di-decode di serial monitor.

Pin strapping: bagaimana GPIO0, GPIO2, GPIO12, dan GPIO15 bisa merusak boot

Ketika ESP32 menyala, ia melihat level pin tertentu untuk memutuskan cara boot. Pin ini disebut pin strapping, dan hanya level-nya pada momen reset yang penting; setelah boot selesai, pin ini bisa dipakai sebagai GPIO biasa. Masalahnya muncul ketika sensor, tombol, atau modul yang kamu sambungkan ke salah satunya menarik pin ke level yang salah ketika boot. Akibatnya board sama sekali tidak menjalankan programnya, masuk ke mode pemrograman, atau tidak bisa membaca flash; dari luar ini juga terlihat seperti “ESP32 tidak mau boot” atau “terus reset”. Peta pin lengkap board-mu bisa kamu lihat di alat diagram pin.

Board yang lebih baru punya pin strapping yang berbeda: di ESP32-S3 yaitu GPIO0, GPIO3, GPIO45, dan GPIO46, dan di ESP32-C3 yang memengaruhi boot adalah GPIO2, GPIO8, dan GPIO9. ESP32-S3 memakai nama exception Xtensa yang sama dengan ESP32 klasik. Tapi di ESP32-C3 yang berbasis RISC-V, kamu akan melihat Load access fault alih-alih LoadProhibited dan Store access fault alih-alih StoreProhibited, dan register MTVAL mengambil alih peran EXCVADDR. Pesan brownout-nya sama di semua model.

ESP32 dan Raspberry Pi Pico di MicroPython

Kalau kamu memprogram ESP32 dengan MicroPython, brownout terjadi dengan cara yang persis sama, karena masalahnya ada di hardware, bukan di perangkat lunak. Sebaliknya, error di kode Python muncul sebagai Traceback yang mudah dibaca, bukan Guru Meditation, dan board jarang crash. Alasan reset bisa kamu baca dengan machine.reset_cause(), tapi hati-hati: port ESP32 MicroPython tidak mengembalikan brownout sebagai nilai tersendiri, melainkan melaporkannya sebagai PWRON_RESET bersama dengan power-on. Kalau board terus menyala dengan PWRON_RESET padahal tidak kamu sentuh, curigai lagi catu dayanya. Kode di bawah untuk ESP32; di Raspberry Pi Pico, modul machine mengenal lebih sedikit jenis reset. Di Pico, regulator buck-boost di input VSYS bekerja dengan tegangan berapa pun dari 1,8 sampai 5,5 V, jadi masalah brownout jauh lebih jarang; untuk mengenal board-nya, lihat Apa Itu Raspberry Pi Pico?

1import machine, gc, time
2
3# Reset nedenleri (ESP32 için) / reset causes (for ESP32)
4causes = {
5    machine.PWRON_RESET: "PWRON: guc acilisi ya da brownout / power-on or brownout",
6    machine.HARD_RESET: "HARD: cokme ya da machine.reset() / crash or machine.reset()",
7    machine.WDT_RESET: "WDT: watchdog",
8    machine.DEEPSLEEP_RESET: "DEEPSLEEP: derin uykudan uyanma / deep sleep wake-up",
9    machine.SOFT_RESET: "SOFT: Ctrl+D ile yazilim reseti / soft reset with Ctrl+D",
10}
11print("Reset nedeni / reset cause:", causes.get(machine.reset_cause(), "bilinmiyor / unknown"))
12
13while True:
14    gc.collect()                                     # çöp toplayıcıyı çalıştır / run the garbage collector
15    print("Bos RAM / free RAM:", gc.mem_free(), "bayt / bytes")
16    time.sleep(5)

Kesalahan umum dan solusinya

Board-mu sudah stabil: selanjutnya apa?

• Perangkat hemat baterai: dengan deep sleep ESP32, tidurkan board di antara pengukuran dan tarik arus di kisaran mikroampere.
• Pembaruan nirkabel: upload kode tanpa kabel USB memakai pembaruan OTA ESP32.
• Dasbor real-time: pantau data sensor secara langsung di browser dengan WebSocket ESP32.
• Kirim notifikasi: dengan bot Telegram ESP32, terima alasan reset di ponselmu setiap kali board restart.
• Pertunjukan cahaya: kendalikan strip WS2812B NeoPixel dengan aman memakai suplai terpisah.

Sebagian besar masalah restart ESP32 adalah masalah daya atau beberapa baris kode yang bermasalah; begitu kamu membaca pesannya dengan benar, keduanya cepat beres. Untuk menyegarkan dasar-dasar board ini, lihat Apa Itu ESP32? Di aplikasi BlueGrays kamu akan menemukan proyek ESP32 dengan LED, servo, strip NeoPixel, koneksi Wi-Fi, web server, pembaruan OTA, dan deep sleep, masing-masing dengan skema rangkaian dan kode langkah demi langkah, jadi kamu bisa mencoba teknik daya dan diagnostik yang kamu pelajari di sini pada proyek sungguhan.