Belajar Hardware Engineer - Measurement & Debugging

#Pendahuluan

Setelah di episode 9 board kalian berhasil di-bring-up — atau mungkin belum sepenuhnya — pada episode ini kalian memegang senjata utama hardware engineer: alat ukur dan debugging. Di sinilah kalian berubah dari "orang yang menyolder" menjadi "detektif yang menemukan kebenaran di balik gejala".

Mengapa measurement & debugging layak mendapat episode khusus? Karena sebagian besar waktu kerja hardware engineer — jujur saja — dihabiskan untuk menemukan mengapa sesuatu tidak bekerja seperti seharusnya. Engineer yang hebat bukan yang tidak pernah membuat kesalahan, melainkan yang bisa menemukan kesalahannya dengan cepat dan terstruktur.

#Tiga Alat Ukur dan Kapan Memakainya

#Multimeter: Mata untuk Dunia Statik

Multimeter mengukur besaran statis: tegangan, arus, resistansi, kontinuitas. Ini alat pertama yang kalian pegang saat board bermasalah.

Fungsi	Cara Pakai	Kapan Dipakai
Tegangan DC	Probe paralel ke titik ukur	Cek rail power, output regulator
Resistansi	Board mati, probe ke dua ujung	Cek short, cek resistor
Kontinuitas	Mode buzzer	Cek sambungan solder, trace putus
Arus	Probe seri (lewatkan arus)	Cek konsumsi total, arus per blok

Pitfall umum: mengukur arus dengan probe paralel — arus diukur seri, bukan paralel. Salah mode pada terminal arus (A) saat mengukur tegangan = korslet fuse.

#Oscilloscope: Mata untuk Sinyal Dinamis

Oscilloscope menampilkan tegangan terhadap waktu — alat wajib untuk power ripple, clock, protokol, dan debugging sinyal. Parameter penting saat memilih/memakai scope:

Bandwidth — rule of thumb: minimal 5x frekuensi sinyal. Untuk clock 8MHz, scope 40-50MHz cukup.
Sample rate — minimal 4-5x bandwidth.
Probe 10x — mengurangi beban kapasitif pada sirkuit, wajib untuk pengukuran akurat.

pengukuran_ripple.txt

1. Pasang probe 10x, copula spring ground ke tip probe (bukan lead panjang!)
2. DC coupling, 10mV/div, 20MHz bandwidth limit
3. Ukur di cap output buck: ripple seharusnya puluhan mV, bukan ratusan
4. Zoom untuk lihat switching spike (transien tajam di tiap cycle)

Teknik probe yang salah — lead ground panjang seperti antena — akan menangkap noise yang tidak benar-benar ada di sirkuit. Untuk pengukuran halus seperti ripple, selalu pakai ground spring.

#Logic Analyzer: Mata untuk Dunia Digital

Logic analyzer merekam level 0/1 pada banyak kanal sekaligus dan mendekode protokol: UART, SPI, I2C. Saat MCU tidak merespons, pertanyaan pertamanya biasanya "apakah data benar-benar keluar?" — jawabannya ada di sini.

sesi_logic_analyzer.txt

1. Sambungkan CH0 -> MCU TX, CH1 -> MCU RX, GND -> GND
2. Set sampling rate >= 5x baud rate (misal UART 115200 -> >= 1MHz)
3. Trigger: rising edge di CH0
4. Setelah capture, pilih "UART decoder": cek byte, baud, format
5. Baca hasil: 0x41 ('A') harus muncul jika MCU mengirim "A"

Logic analyzer dengan decoder protokol adalah cheat code: ia mengubah "kenapa tidak ada data?" menjadi "data 0x4A yang datang bukan 0x41".

#Metodologi Debugging Sistematis

Debugging hardware tanpa metode adalah tebakan beruntun. Dua kerangka yang dipakai luas di industri:

#Divide and Conquer

Pecah sistem menjadi blok, lalu persempit. Mulai dari tempat paling awal di alur sinyal:

Power ada? — ukur semua rail di titik beban (bukan di sumber!).
Clock hidup? — oscilloscope di pin OSC.
Reset lepas? — cek pin reset sudah di level high.
MCU berjalan? — cek blink LED / toggling pin di firmware minimal.
Interface jalan? — logic analyzer di jalur TX/RX.

Setiap "ya" mempersempit pencarian ke blok berikutnya. Setiap "tidak" menandai blok bermasalah.

#20/20/60

Distribusi waktu debugging yang ditemukan praktisi:

20% waktu untuk memahami sistem dan menggambar diagram blok.
20% waktu untuk menulis ulang hipotesis berdasarkan pengukuran.
60% waktu benar-benar mengukur dan menguji.

Jika kalian menghabiskan 60% waktu untuk berpikir dan hanya 20% untuk mengukur, kalian melakukan debugging secara terbalik.

Tip

Satu pertanyaan yang mengubah debugging selamanya: "Apa buktinya?" Sebelum mengganti komponen atau mencurigai chip, tanyakan apa pengukuran yang mendukung hipotesis itu. Engineer yang mencurigai berdasarkan firasat akan mengganti komponen yang sehat dan menolak mengukur jalur yang bermasalah.

#Praktik: Sesi Debug Nyata

Mari berlatih dengan skenario klasik: board tidak mengirim data UART.

log_sesi_debug.txt

GEJALA: MCU tidak mengirim apa pun ke PC lewat UART
 
1. Ukur 3V3 di pin MCU        -> 3.28V  OK
2. Ukur GND antara board dan USB-Serial -> 0.2 ohm  OK
3. Oscilloscope di pin OSC    -> 8MHz sinyal bersih  OK
4. Cek pin reset              -> 3.3V (high, tidak reset)  OK
5. Logic analyzer di TX       -> tidak ada aktivitas!
   HIPOTESIS: firmware tidak jalan atau pin salah muxing
6. Blink LED di firmware       -> LED nyala! MCU jalan, firmware jalan
   KESIMPULAN: masalah di konfigurasi pin/peripheral UART
7. Baca datasheet: TX di PA9  -> ya, firmware memakai PA10/PA11
   BUG: pin salah -> ganti ke PA9/PA10, recompile, retest
   VERIFIKASI: logic analyzer menampilkan 0x41 'A'  FIXED

Perhatikan polanya: setiap langkah diuji dengan alat ukur, bukan ditebak. Ketika hipotesis "firmware tidak jalan" terbukti salah (LED blink), arah pencarian berpindah — dan bug ditemukan dalam hitungan menit.

Warning

Saat board terlihat "hidup" tanpa probe tapi mati saat probe dilepas, dan saat masalah datang-pulang secara acak, jangan buru-buru salahkan komponen. Periksa dulu hal paling membosankan: koneksi yang longgar, solder yang retak, dan kabel yang putus di isolasinya. Sembilan dari sepuluh bug "misterius" adalah masalah mekanis.

#Penutup

Pada episode 10 ini, kalian telah menguasai tiga alat ukur dan kerangka debugging yang mengubah tebakan menjadi pengukuran.

Inti yang harus dibawa pulang:

Multimeter untuk statik (rail, short, kontinuitas); oscilloscope untuk dinamis (ripple, clock, sinyal); logic analyzer untuk bus digital.
Probe yang benar menentukan akurasi: ground spring untuk ripple, probe 10x untuk beban rendah.
Divide and conquer: sempitkan dari power → clock → reset → MCU → interface.
Aturan 20/20/60: mengukur jauh lebih produktif daripada merenung.
Satu pertanyaan pemaksa: "Apa buktinya?"

Di episode 11 selanjutnya kita menjembatani dua dunia: firmware-hardware interface — GPIO, interrupt, dan batas tanggung jawab antara desain hardware dan firmware, lengkap dengan dokumen interface spec. Sampai jumpa di episode 11!