Cara Debug Perangkat IoT Berbasis Zephyr: Praktik Pantau Jarak Jauh Teruji

Proyek Sumber Terbuka Zephyr Linux Foundation telah menjadi sumbu untuk banyak solusi IoT. Dengan sistem operasi real-time (RTOS) yang ringan, dapat diskalakan, dan dirancang untuk perangkat dengan sumber daya terbatas, Zephyr mendukung spektrum luas arsitektur—ARC, Arm, Intel, Nios, RISC-V, SPARC, Tensilica—dan lebih dari 250 papan. Saat ini, proyek ini memiliki 1.000 kontributor dan 50.000 commit, terus memperluas jangkauan multi-arsitektur.

Mengembangkan untuk Zephyr memerlukan perhatian pada keandalan. Masalah yang muncul di lab seringkali hanya hilang saat perangkat diskala, atau saat tumpukan jaringan berkembang. Strategi pemantauan dan debug jarak jauh yang kuat esensial untuk mendeteksi, mendiagnosis, dan menyelesaikan masalah sebelum mereka diterjemahkan menjadi waktu henti yang mahal.

Pertimbangkan kerja kami dengan pelacak GPS untuk pemantauan ternak. Setiap kalung harus beroperasi dengan lancar di seluruh beberapa jaringan seluler, negara, dan zona roaming. Penggunaan daya yang tidak terduga karena konfigurasi yang salah akan mengakibatkan kerugian ekonomi yang signifikan. Kami tidak hanya perlu menandai masalah, tetapi memahami penyebab akarnya dan menerapkan perbaikan—dari itu kebutuhan akan observabilitas waktu nyata dan jarak jauh.

Kami menggabungkan Zephyr dengan Memfault, platform observabilitas perangkat berbasis cloud, untuk membangun tumpukan pemantauan yang mencakup pembaruan firmware, reboot, watchdog, kesalahan, asserts, dan metrik konektivitas.

Menyiapkan Platform Observabilitas

Memfault memberdayakan pengembang untuk memantau, debug, dan meluncurkan perubahan firmware dari jarak jauh, memungkinkan:

• Peluncuran produksi yang mulus yang menghindari pendinginan
• Pemantauan kesehatan berkelanjutan dari armada perangkat
• Patch tanpa waktu henti yang diberikan sebelum pengguna menyadari masalah

Mengintegrasikan SDK Memfault ke Zephyr sederhana: tambahkan modul ke manifest west.yml Anda dan aktifkan di prj.conf.

# west.yml [ ... ] - name: memfault-firmware-sdk url: https://github.com/memfault/memfault-firmware-sdk path: modules/memfault-firmware-sdk revision: master # prj.conf CONFIG_MEMFAULT=y CONFIG_MEMFAULT_HTTP_ENABLE=y

1️⃣ Fokus pada Reboot

Tingkat reset yang meningkat seringkali adalah tanda pertama dari masalah yang lebih dalam—degradasi perangkat keras, bug firmware, atau anomali jaringan. Dengan membedakan antara reset perangkat keras dan perangkat lunak, Anda dapat menentukan apakah kesalahan meluas atau terisolasi pada subset perangkat.

Catat alasan sebelum reboot

void fw_update_finish(void) { // … memfault_reboot_tracking_mark_reset_imminent(kMfltRebootReason_FirmwareUpdate, ...); sys_reboot(0); }

Zephyr melestarikan wilayah yang ditentukan pengguna di seluruh reset; Memfault mencengkeruk ini untuk menangkap konteks reboot. Setelah reboot, daftarkan handler init untuk membaca alasan reset perangkat keras dan mengirimkannya ke cloud.

static int record_reboot_reason(void) { // 1. Baca register alasan reset perangkat keras (lihat datasheet MCU) // 2. Tangkap alasan reset perangkat lunak dari RAM noinit // 3. Kirim data ke server untuk agregasi } SYS_INIT(record_reboot_reason, APPLICATION, CONFIG_KERNEL_INIT_PRIORITY_DEFAULT);

Contoh: kekurangan suplai daya dapat muncul sebagai ribuan reboot dalam waktu singkat. Gambar 1 menunjukkan armada di mana 99 % dari 12.000 reboot per hari ditandai pada hanya sepuluh perangkat—kemungkinan masalah mekanis atau baterai. Pembaruan firmware dapat mengatasi masalah tersebut, tetapi pemantauan jarak jauh memungkinkan Anda mendeteksi dan mengatasi sebelum mereka membesar.

• 12K reboot perangkat sehari – terlalu banyak
• 99% reboot dari 10 perangkat
• Celah mekanis yang menyebabkan reset konstan

2️⃣ Manfaatkan Watchdog

Watchdog adalah garis pertahanan terakhir Anda terhadap kegagalan—baik yang disebabkan oleh tumpukan jaringan yang terblokir, loop tak terbatas, deadlock, atau kerusakan memori. Zephyr menyediakan API watchdog terpadu yang mengabstraksi perbedaan perangkat keras.

void start_watchdog(void) { struct device *s_wdt = device_get_binding(DT_LABEL(DT_INST(0, nordic_nrf_watchdog))); struct wdt_timeout_cfg wdt_config = { .flags = WDT_FLAG_RESET_SOC, .window.min = 0U, .window.max = WDT_MAX_WINDOW, }; s_wdt_channel_id = wdt_install_timeout(s_wdt, &wdt_config); const uint8_t options = WDT_OPT_PAUSE_HALTED_BY_DBG; wdt_setup(s_wdt, options); } void feed_watchdog(void) { wdt_feed(s_wdt, s_wdt_channel_id); }

Untuk Nordic nRF9160, alur kerja tipis adalah:

1. Konfigurasikan device tree untuk watchdog.
2. Setel parameter melalui API.
3. Pasang watchdog.
4. Berikan makan secara berkala; makan yang terlewat memicu reboot dan handler kesalahan Zephyr.

Memfault menangkap keadaan sebelum reset, memungkinkan Anda melacak kembali ke jalur kode yang bersalah. Contoh: driver SPI yang macet setelah 16 bulan penerapan terungkap oleh kesalahan yang diinisiasi watchdog. Gambar 2 mengilustrasikan garis waktu dan degradasi, sementara Gambar 3 menunjukkan dump register handler kesalahan.

3️⃣ Tangani Kesalahan dan Asserts

Ketika assert atau kesalahan memicu, handler kesalahan Zephyr menangkap keadaan CPU. Memfault secara lancar mencengkeruk alur ini, mempertahankan register, konteks kernel, dan snapshot semua tugas aktif ke cloud.

void network_send(void) { const size_t packet_size = 1500; void *buffer = z_malloc(packet_size); // Missing NULL check leads to fault memcpy(buffer, 0x0, packet_size); } bool memfault_coredump_save(const sMemfaultCoredumpSaveInfo *save_info) { // Store register state, kernel & task contexts, selected .bss/.data } void sys_arch_reboot(int type) { // … }

Diagnostik kunci termasuk:

1. Register status kesalahan Cortex-M menunjukkan penyebab.
2. Memfault memulihkan baris kode yang tepat dan keadaan tugas sekitarnya.
3. Struktur _kernel mengungkap status jadwal dan, untuk tumpukan yang terhubung, parameter Bluetooth atau LTE.

4️⃣ Lacak Metrik Tingkat Perangkat

Metrik memberikan tampilan yang dapat diukur tentang kesehatan armada. Nilai yang biasanya dipantau termasuk beban CPU, metrik konektivitas, dan data termal. SDK Memfault memungkinkan Anda mendeklarasikan dan melaporkan metrik dengan kode minimal.

1. Definisikan metrik

MEMFAULT_METRICS_KEY_DEFINE( LteDisconnect, kMemfaultMetricType_Unsigned)

2. Perbarui dalam kode

void lte_disconnect(void) { memfault_metrics_heartbeat_add( MEMFAULT_METRICS_KEY(LteDisconnect), 1); // … }

Backend cloud Memfault mengagregasikan metrik menurut perangkat dan versi firmware, menyediakan UI web untuk membandingkan armada dan memicu peringatan. Kasus penggunaan umum:

• Konektivitas NB-IoT/LTE-M: pantau status daya modem untuk mengukur dampak baterai.
• Peristiwa menara sel dan waktu PSM: identifikasi titik panas kualitas sinyal yang menguras daya.
• Telemetri armada besar: spot outlier dan lonjakan data yang tidak terduga.

• Ukuran data UDP per interval pengiriman.
• Lonjakan data setelah reboot.
• Paket besar menunjukkan jejak atau diagnostik tertanam.
• Gunakan metrik untuk mengontrol penggunaan dan biaya data.

Kesimpulan

Dengan mengintegrasikan Zephyr dengan Memfault, pengembang memperoleh tumpukan observabilitas akhir ke akhir yang kuat. Fokus pada empat pilar—reboot, watchdog, kesalahan/asserts, dan metrik konektivitas—dan Anda akan mengubah armada perangkat dari kotak hitam yang tidak transparan menjadi sistem yang transparan dan dapat dikelola. Untuk wawasan yang lebih dalam, tonton presentasi yang direkam dari Zephyr Developer Summit 2021.