STM32 + NetBeans =?

Seperti yang Anda ketahui, kompatibilitas dengan alat GNU dan dukungan untuk GDB membuat hampir semua lingkungan pengembangan populer cocok untuk debugging berbagai platform tertanam, paling sering gratis dan legal. Secara teori.

Apa yang terjadi dalam praktik ketika mencoba berteman dengan STM32 dan NetBeans, dan apakah mungkin, pada prinsipnya, untuk mendapatkan sistem yang bisa diterapkan dengan dukungan untuk batu-batu terbaru - di bawah potongan.

Beberapa lirik

Saya benar-benar tidak ingin meninggalkan microchip. Namun, setelah pembelian oleh Atmela, mereka pertama kali menutupi, mungkin, salah satu keluarga paling menjanjikan dalam portofolio perusahaan - PIC32MM, dan kemudian seluruh lini MIPS. Menjadi jelas bahwa di masa mendatang, transisi ke ARM tidak dapat dihindari, karena microchip selama dua tahun belum mengintegrasikan dukungan pengontrol Atmelovsk dalam ekosistemnya, itu tidak memberikan keuntungan apa pun untuk "Tetap bersama kami". Sebaliknya, kebijakan harga ke atas dan kesulitan organisasi tradisional dari merger membuat AWP Atmelovskiye kurang menarik. Pada saat yang sama, sebuah proyek muncul bahwa PIC32MZ hanya tersandung. Massa kritis telah diperoleh.

Mengapa STM: cakupan pasar yang luas, debugging anggaran, lingkungan open source berfitur lengkap SW4STM32 berbasis pada teknologi open source, dan aspek politik - ST Mikroelektronika didukung oleh pemerintah Prancis sebagai sumber daya strategis, sehingga keluar tiba-tiba dari pasar atau pengambilalihan, tampaknya, tidak terancam.

Debugging - Kesan Pertama

SW4STM32 dipasang dengan cara tradisional - dengan berulang kali menekan tombol Next> (* selanjutnya, semua percobaan berlangsung pada Win7 x64). Sebuah proyek demo yang cocok untuk menguji fungsi yang diinginkan telah dihapus dari paket STM32Cube Firmware, semuanya bekerja kurang lebih langsung dari kotak. Awal pertama dari emulator JTAG meninggalkan kesan: seluruh siklus memasuki mode debug, mulai dari koneksi dan berakhir dengan berhenti di awal main () dengan memperbarui konteks, ternyata, bisa muat dalam 1-2 detik. Dibandingkan dengan debuggers microchip (bahkan ICE NYATA untuk setengah setengah), perbedaan dalam kecepatan adalah beberapa!
Namun, sesuatu yang mengejutkan tidak menyenangkan.

Apa yang salah dengan Eclipse / SW4STM32

Segudang pengaturan dan organisasi tidak logis, item menu tersembunyi, perspektif, bug antarmuka dan artefak visual, tombol dan fungsi panas yang jarang digunakan pada bilah alat, piktogram dan spidol kecil yang kikuk dan tidak dapat dibaca, tidak adanya "Temukan Penggunaan" sebagian subjektif, dan Anda dapat beradaptasi jika Anda mau . Tetapi: secara teratur lupa untuk menyimpan file yang dimodifikasi sebelum perakitan, meskipun semua tanda centang diperlukan; dengan penghematan manual paksa, itu tidak melihat perubahan, dan perakitan tambahan ternyata tidak relevan; tidak ada pembangunan kembali lengkap (Bersihkan dan Bangun) sebagai satu tim, dan setelah pembersihan paksa melalui Proyek Bersih, perakitan gagal (akses file?) dan berhasil menyelesaikan hanya setelah upaya ke-4 - ini tidak lagi dapat dijelaskan secara wajar. Bahkan rilis MPLAB X Beta awal berdasarkan NetBeans 6.xx kuno tidak memiliki masalah yang sama 10 tahun yang lalu sebagaimana lingkungan pengembangan yang didukung secara resmi untuk STM32 miliki saat ini.

Selain itu, dengan SW4STM32, 3 salinan IDE khas sudah dipanggil dalam sistem, karena selain itu masih ada MPLAB X yang dipaku kuat ke NetBeans 8.0.1 dan agak dipagari (mis. Tidak mungkin menggunakannya untuk bahasa / platform lain), dan NetBeans 8.2 untuk Java dan C / C ++.

Ternyata pengaturan NetBeans 8.2 untuk bekerja dengan STM32 akan menghilangkan masalah praktis yang dijelaskan Eclipse, mengurangi jumlah salinan IDE, dan menguranginya menjadi satu platform, meskipun versi yang sedikit berbeda.

NetBeans 8.2 dan GNU ARM Tools

NetBeans lebih baik menggunakan 32-bit, karena selain menggandakan konsumsi memori, perbedaan versi 64-bit tidak dapat ditemukan.

Google dengan cepat menemukan panduan pengaturan . Perbedaan utama hanya pada OS (mereka memiliki Linux melawan Win7 x64 untuk saya), jadi menginstal MSYS * nix-environment, yang termasuk dalam paket MinGW, menjadi permainan hadiah. Pengaturan Toolchain akan terlihat seperti ini:


Poin penting - saat menambahkan GNU ARM toolchain, pilih keluarga "GNU MinGW", dalam hal ini NetBeans akan memanggil MSYS dengan benar. Jika Cygwin sudah diinstal pada mesin, akan logis untuk menggunakannya, oleh karena itu, keluarga ARM GNU harus memilih "GNU Cygwin".

Mencapai kompilasi yang sukses itu tidak mudah, tetapi sangat sederhana. Karena SW4STM32 menggunakan kompiler yang sama, melihat baris perintah panggilan kompiler di SW4STM32 dan menyalin kunci yang hilang di Properti Proyek → C Compiler → Opsi Tambahan


kami mendapatkan hasil keluaran yang persis sama, tetapi dengan perbedaan praktis yang penting - semuanya dikumpulkan pertama kali, ada Clean and Build dan berfungsi dengan baik:


Tetapi hasil ini juga dapat ditingkatkan dengan menambahkan pemrosesan Post-Build opsional. Buka Makefile, dan di bagian .build-post: .build-impl tambahkan:

.build-post: .build-impl cp ${CND_DISTDIR}/${CONF}/${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}} arm-none-eabi-objcopy -O ihex ${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}}.hex arm-none-eabi-size ${CND_ARTIFACT_NAME_${CONF}} 

(penting - indentasi harus karakter tab tunggal, bukan spasi)
Baris demi baris: 1 - menyalin file objek (diri sendiri) dari folder output ke root proyek, untuk akses yang lebih mudah; 2 - menghasilkan HEX dari elf (dapat dikomentari jika HEX tidak diperlukan); 3 - menampilkan jumlah memori yang ditempati berdasarkan segmen.

Hasil akhirnya:


Sejauh ini bagus.

OpenOCD - kesulitan pertama

Dalam manual online yang disebutkan di atas, pemrograman chip melalui OpenOCD sederhana dan rutin. Versi terbaru (0.10.0) diinstal, file konfigurasi diambil (dari kit OpenOCD atau dari folder proyek SW4STM32), perintah formulir ditulis dalam Project Properties → Run:


dan semuanya langsung bekerja. Memang, ini adalah kasus untuk keluarga muda seperti STM32F103 dan F407, tapi saya tertarik pada F7 dan H7. Dengan yang pertama, versi resmi OpenOCD 0.10.0 lumpuh dengan kesalahan "auto_probe gagal" dan "alasan debug 7 tidak ditentukan"; yang terakhir tidak didukung sama sekali. Kami mencoba semua majelis resmi yang tersedia 0,10.0 dari Jan 2017 dan Jan 2018 - hasilnya identik. Pencarian kata kunci mengonfirmasi keberadaan masalah, meskipun Anda tidak dapat menyebutkannya secara masif; tidak ada analisis dan solusi.

Tetapi ada versi yang dijamin berfungsi - dari kit SW4STM32. Secara alami, itu ternyata ditingkatkan dan ditambah, dengan skrip baru dan dukungan untuk keluarga H7. Selain itu, struktur file telah diubah di dalamnya, dan di plug-in sumber daya disimpan dalam modul terpisah, oleh karena itu, agar utilitas dikonsolidasikan dalam satu folder untuk melihat skripnya, saklar -s diperlukan.

Board.cfg untuk NUCLEO-F767ZI, setelah komentar, dan terkondensasi:

 set CHIPNAME STM32F767ZITx source [find interface/stlink-v2-1.cfg] transport select hla_swd source [find target/stm32f7x.cfg] set WORKAREASIZE 0x10000 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 reset_config srst_only srst_nogate connect_assert_srst set CONNECT_UNDER_RESET 1 

Akhirnya diluncurkan melalui Run Main Project:


Firmware berhasil, kode sedang dijalankan.

Debugging

Skema ini diasumsikan sebagai yang paling tradisional: server GDB lokal pada OpenOCD, NetBeans terhubung melalui localhost: 3333 via TCP. Dengan demikian, NetBeans akan membutuhkan plugin Gdbserver.

Dimungkinkan untuk menyederhanakan peluncuran OpenOCD melalui skrip kelelawar, dan karena setelah sesi selesai, buka konsol, masuk akal untuk mengulang restart tanpa henti:

 :start openocd -f debug.cfg -sd:/Prog/openocd/scripts goto start 

Luncurkan:


Versi dari SW4STM32 tidak ditulis secara eksplisit, tetapi server sedang menunggu koneksi TCP ke port 3333. Di NetBeans, pilih Debug → Lampirkan Debugger ..., dan instal:


Sesi ini aktif. Terminal OpenOCD:


Dalam penampilan, semuanya terlihat baik - sesi debug aktif, kode dieksekusi. Namun, masalahnya masih ada.

Masalah

Dalam mode jalankan bebas, eksekusi tidak dapat dihentikan.

Jika Anda menetapkan breakpoint sebelum memulai sesi, ketika Anda memasukkan debugging, itu akan berhenti dengan memperbarui konteks, eksekusi langkah-demi-langkah dan melihat / mengubah variabel akan bekerja, yaitu, pada prinsipnya, semua fungsi dasar yang diperlukan untuk debugging penuh:


Tetapi hanya sampai awal bebas berikutnya, setelah itu tetap hanya menutup dan memulai kembali sesi.

Agak tidak menyenangkan lain dikaitkan dengan breakpoints perangkat lunak: fungsi SYSTEM_Halt () didefinisikan sebagai __asm__ ("bkpt"), dan operasinya mengarah ke tampilan dialog yang tidak perlu:


Ketika Anda mengklik Buang dan Jeda itu berfungsi seperti yang diperlukan (yaitu, itu menghentikan eksekusi), namun, tidak mungkin untuk mengatur opsi ini secara default dan mematikan tampilan jendela dengan cara standar.

Sebelum heap, saya ingin mengotomatiskan peluncuran OpenOCD dan menghubungkan debugger secara langsung melalui NetBeans.

Namun, secara objektif, satu-satunya fungsi yang tidak cukup untuk debugging kurang lebih lengkap adalah untuk menghentikan eksekusi (itu juga diperlukan untuk mengatur breakpoint on the fly).

Debug Debugging

Pencarian google mengungkapkan bahwa masalah yang sama dengan NetBeans menghentikan GDB berhenti, tetapi diperbaiki beberapa tahun yang lalu. Karena kurangnya ide yang lebih baik, sumber-sumber NetBeans diunduh dengan harapan dapat berjalan melalui debugger secara langsung. Anehnya, kami dapat dengan cepat melokalisasi masalah sebelum memanggil utilitas eksternal GdbKillProc.exe, yang pada dasarnya adalah pembungkus untuk DebugBreakProcess (pid) dari WinAPI. Prinsip utilitas dikurangi menjadi gangguan proses yang tidak mengganggu (analog dengan “kill -SIGINT [pid]” di bawah * nix, atau Ctrl + C di konsol).

Tapi dia tidak bekerja.

Apa yang diuji

Dalam mode konsol, klien GDB (arm-none-eabi-gdb.exe) bereaksi dengan benar terhadap Ctrl + C, artinya, menghentikan eksekusi kode tanpa menutup sesi, dan menunggu instruksi lebih lanjut.

ps -W dan Windows Process Explorer menampilkan proses dengan benar, dan PID cocok dengan variabel internal di NetBeans.

Panggilan manual "kill -SIGINT [pid]" dari paket MSYS melempar kesalahan "No such process".

Memeriksa melalui "taskkill / pid [pid]" menghasilkan "Proses ... tidak dapat dihentikan ... Proses ini hanya dapat dihentikan dengan paksa ...", yang tampaknya menunjukkan kunci sistem. Dengan sakelar / f, proses menutup sepenuhnya, yang juga tidak bagus.

Dalam prosesnya, ternyata di Windows, situasi dengan generasi sinyal interupsi tidak masalah, atau lebih tepatnya, sama sekali tidak: hanya analog SIGTERM yang didukung secara default, yang berhubungan dengan pemotongan kasar dari proses tersebut, dan tidak ada solusi yang diterima secara umum.

Di Internet, utilitas windows-kill ditemukan, dirancang untuk meniru Ctrl + C dan Ctrl + Brk. Proses menemukan interupsi mengirim tanpa kesalahan, tetapi klien GDB masih tidak merespons.

Eksperimen dilakukan menggunakan semua versi 32-bit (NetBeans, ARM Tools, MSYS 1.0), kecuali untuk windows-kill, yang menolak untuk memulai 32-bit ("... tidak dapat memulai dengan benar ..."). Mungkin masalahnya persis seperti ini, karena, menurut data yang terpisah dari forum dan bugtracker, kedalaman bit dari utilitas dan prosesnya harus bersamaan. Kesulitan di sini adalah bahwa ARM tidak menawarkan versi x64 dari toolchain untuk Windows, termasuk satu-satunya cara untuk menghilangkan heterogenitas adalah dengan membuat versi x32 dari windows-kill bekerja, yang juga tidak jelas apakah mungkin berdasarkan Win x64 pada prinsipnya.

Di tengah proses, OS diinstal ulang dari awal, dan tidak ada perubahan dalam perilaku subjek eksperimental yang diperhatikan, termasuk dengan keyakinan besar fitur-fitur sistem tertentu dapat dihilangkan.

Diperlukan bantuan aula

Sebenarnya, semua hal di atas dapat dianggap sebagai pengantar paragraf ini.
Langkah terakhir yang tersisa adalah membuat debugging STM32 di bawah NetBeans nyata:

membutuhkan mekanisme perangkat lunak yang berfungsi untuk mengirim sinyal interupsi SIGINT (Ctrl + C) ke proses klien Windows GDB

Berikut ini adalah rekomendasi untuk mengatur konfigurasi minimum yang cukup untuk memverifikasi / men-debug masalah di atas. Jika / ketika itu dapat diatasi, artikel akan diulang kembali dalam panduan langkah demi langkah sederhana tentang cara mengkonfigurasi NetBeans + OpenOCD untuk beberapa keluarga dan papan debug yang berbeda. Fungsi lebih lanjut dapat diselesaikan sesuka hati, sudah memiliki solusi dasar yang bisa diterapkan.

Pengaturan tes

Diusulkan untuk menggunakan papan Blue Pill berdasarkan STM32F103C8T6 dan klon ST-Link V2 sebagai platform perangkat keras.


Itu perlu:

1. Instal GNU Arm Embedded Toolchain

2. Instal OpenOCD 0.10.0 ( build di bawah Win )

3. Daftarkan folder nampan dari kedua paket di PATH (Panel Kontrol → Sistem → Pengaturan Sistem Lanjut → Variabel Lingkungan ... → Jalur).

4. Di tempat yang nyaman untuk membuat file board.cfg, salin isinya:

 source [find interface/stlink-v2.cfg] source [find target/stm32f1x.cfg] transport select "hla_swd" reset_config none separate set WORKAREASIZE 0x5000 set CHIPNAME STM32F103C8T6 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 set CLOCK_FREQ 4000 set CONNECT_UNDER_RESET 1 

5. Pilih firmware uji yang sesuai (test.elf), kriteria utamanya adalah eksekusi dan berhenti dapat dibedakan dengan jelas. Salin ke tempat yang nyaman.

6. Dari tempat yang nyaman untuk mem-flash papan:

openocd -f board.cfg -c "program test.elf verify reset exit"

Firmware harus dimulai. Contoh keluaran OpenOCD ke konsol:


7. Dari tempat yang nyaman untuk memulai server OpenOCD GDB:

openocd -f board.cfg

Kode masih dieksekusi; contoh output (konsol tetap terkunci oleh OpenOCD):


8. Di konsol lain atau langsung jalankan arm-none-eabi-gdb.exe dari paket GNU ARM Embedded Toolchain dan jalankan perintah:

target extended-remote localhost:3333 (kode masih mengeksekusi)
continue (kode sedang berjalan, konsol terkunci)
Ctrl+C (kode berhenti, konsol aktif)
continue (berjalan lagi, konsol terkunci)


Tugasnya adalah menghapus klien GDB dari status eksekusi (mis. Pada dasarnya meniru Ctrl + C) secara terprogram.

Untuk mengetahui ID Proses, gunakan "ps -W" dari lingkungan * nix, atau Windows Process Explorer (diinstal secara opsional).

Mungkin seseorang akan melakukan debug dengan benar tepat setelah penyetelan awal NetBeans - informasi semacam itu juga akan berguna, terutama dengan deskripsi terperinci tentang sistem dan kemungkinan fitur.

Silakan bagikan gagasan dalam komentar, dan saya berharap bahwa dengan bekerja bersama kita dapat mengubah eksperimen yang berani menjadi panduan yang berguna untuk menyiapkan alat yang bahkan lebih berguna.