Hubris adalah lingkungan operasi mikrokontroler yang dirancang untuk sistem yang tertanam dalam dengan persyaratan keandalan. Desainnya pada awalnya diusulkan dalam RFD41, tetapi telah berevolusi sejak saat itu.
Dokumentasi pengembang ada di ASCIIDOC di doc/
Direktori. Ini akan diterjemahkan melalui halaman github, dan tersedia di https://oxidecomputer.github.io/hubris.
Repo diletakkan sebagai berikut.
app/
Di mana peti biner tingkat atas untuk aplikasi hidup, misalnya app/gimlet
berisi peti firmware untuk gimlet. Secara umum, jika Anda ingin membangun gambar untuk sesuatu, lihat di sini.
build/
berisi sistem build dan peti pendukung.
chip/
berisi definisi periferal dan debugging file dukungan untuk mikrokontroler individu.
doc/
berisi dokumentasi pengembang.
drv/
berisi driver, campuran peti Lib driver sederhana dan peti tempat sampah server yang sepenuhnya. Konvensi saat ini adalah bahwa drv/SYSTEM-DEVICE
adalah driver untuk DEVICE
pada SYSTEM
(di mana SYSTEM
biasanya merupakan nama SOC), sedangkan drv/SYSTEM-DEVICE-server
adalah server Bin Crate.
idl/
berisi definisi antarmuka yang ditulis dalam idola
lib/
berisi berbagai macam perpustakaan utilitas yang telah kami tulis. Jika Anda perlu membuat peti yang dapat digunakan kembali yang tidak cocok dengan salah satu direktori lainnya, itu mungkin ada di sini.
stage0/
adalah bootloader/ hypovisor, terutama untuk LPC55.
support/
berisi beberapa file dukungan antarmuka dan pemrograman, seperti sertifikat palsu dan gambar firmware programmer.
sys/
berisi bit "sistem" hubris, yaitu kernel ( sys/kern
), peti bersama yang mendefinisikan abi ( sys/abi
), dan perpustakaan pengguna yang digunakan oleh tugas ( sys/userlib
).
task/
berisi tugas yang dapat digunakan kembali yang bukan driver. Perbedaan antara hal-hal yang hidup dalam task
vs dalam drv/something-server
adalah fuzzy. Gunakan penilaian Anda.
test/
Berisi kerangka kerja uji dan peti biner untuk membangunnya untuk berbagai papan.
website/
Berisi kode sumber untuk situs web hubris
Kami saat ini mendukung Linux dan Windows sebagai platform tingkat pertama. MacOS juga digunakan setiap hari oleh karyawan oksida, tetapi tidak diuji dalam CI. Bangunan mungkin juga berfungsi pada Illumos; Jika ada yang ingin melangkah untuk mempertahankan dukungan dan build yang berkelanjutan untuk Illumos atau MacOS, kami akan menyukai bantuannya.
Untuk mengirimkan perubahan untuk ditinjau, dorong mereka ke cabang di garpu dan kirimkan permintaan tarik untuk menggabungkan cabang itu menjadi master
. Untuk detailnya, lihat CONTRIBUTING.md
.
Anda akan membutuhkan:
Instalasi toolchain berbasis rustup
. rustup
akan mengurus secara otomatis menginstal versi toolchain kami yang disematkan, dan target kompilasi silang, ketika Anda pertama kali mencoba membangun.
openocd
(idealnya 0,11) atau (jika menggunakan LPC55) pyocd
(0,27 atau lebih baru). Perhatikan bahwa rilis 0,10 OpenOCD mendahului Stlink V3. Orang-orang menggunakan berbagai pasca-0.10, pra-0.11 build yang disediakan oleh manajer paket sistem, dengan beberapa keberhasilan, tetapi jika sistem Anda belum mengemas 0.11, selaras mereka. Jika Anda akan menggunakan homebrew di macOS untuk menginstal OpenOCD, Anda perlu menggunakan brew install --head openocd
untuk membangun ujung cabang utama daripada menggunakan rilis biner terbaru. Jika Anda perlu membangun dari sumber, Anda dapat menemukan OpenOCD V0.11.0 di sini. Saat menjalankan ./configure
, pastikan Anda melihat bahwa ST-Link Programmer
diatur diaktifkan (yang seharusnya default).
libusb, biasanya ditemukan dari manajer paket sistem Anda sebagai libusb-1.0.0
atau serupa.
libfdti1, ditemukan sebagai libftdi1-dev
atau serupa.
Jika Anda akan menjalankan GDB, Anda harus menginstal arm-none-eabi-gdb
. Ini biasanya dari manajer paket sistem Anda dengan nama paket seperti arm-none-eabi-gdb
atau gdb-multiarch
. Pengguna MacOS dapat menjalankan brew install --cask gcc-arm-embedded
untuk menginstal binari lengan resmi.
Debugger keangkuhan, kerendahan hati. Perhatikan bahwa cargo install
berinteraksi secara aneh dengan file rust-toolchain.toml
yang ada di akar repositori ini; Jika Anda menjalankan perintah berikut Verbatim untuk menginstal kerendahan hati, lakukan dari direktori yang berbeda:
cargo install --git https://github.com/oxidecomputer/humility.git --locked humility
cargo-readme
sebagai ketergantungan: cargo install cargo-readme
Ada tiga cara alternatif untuk menginstal OpenOCD:
Lihat di sini untuk mendapatkan sumber openocd
atau mendapatkan biner tidak resmi.
Atau, Anda dapat menginstal dengan cokelat:
> choco install openocd
Terakhir, Anda dapat menginstal openocd
dengan scoop:
> scoop bucket add extras
> scoop install openocd
Catatan: openocd
yang diinstal melalui scoop
telah terbukti bermasalah bagi beberapa pengguna. Jika Anda mengalami masalah, coba instal melalui choco
atau dari sumber (lihat di atas).
Untuk menggunakan programmer ST-Link, Anda mungkin perlu menginstal driver ini.
Tidak perlu membangun dan menjalankan keangkuhan, tetapi jika Anda ingin berkomunikasi melalui tautan serial (dan itu tidak didukung oleh terminal Anda), Anda ingin menggunakan dempul; Panduan ini melakukan pekerjaan yang baik untuk menjelaskan caranya.
Kami tidak menggunakan cargo build
atau cargo run
secara langsung karena mereka terlalu tidak fleksibel untuk tujuan kami. Kami memiliki build multi-arsitektur yang kompleks, yang sedikit melampaui mereka.
Sebagai gantinya, repo menyertakan ekstensi kargo yang disebut xtask
yang menamai perintah pembuatan kustom kami.
cargo xtask dist TOMLFILE
Membangun gambar distribusi untuk aplikasi yang dijelaskan oleh file TOML.
cargo xtask dist app/demo-stm32f4-discovery/app.toml
-STM32F4-Discoverycargo xtask dist app/demo-stm32f4-discovery/app-f3.toml
-STM32F3-DISCOVERYcargo xtask dist app/lpc55xpresso/app.toml
- LPCXPRESSO5S69cargo xtask dist app/demo-stm32g0-nucleo/app-g031.toml
-STM32G031-NUCLEOcargo xtask dist app/demo-stm32g0-nucleo/app-g070.toml
-STM32G070-NUCLEOcargo xtask dist app/demo-stm32h7-nucleo/app-h743.toml
-Nucleo-IH743ZI2cargo xtask dist app/demo-stm32h7-nucleo/app-h753.toml
-Nucleo-IH753ZIcargo xtask dist app/gemini-bu/app.toml
- Papan Gemini Bringup Karena build gambar penuh dapat memakan waktu 10 detik atau lebih, tergantung pada apa yang telah Anda ubah, ketika Anda mengulangi tugas atau kernel Anda mungkin ingin membangunnya secara terpisah. Inilah tujuan dari cargo xtask build
.
Misalnya, untuk membangun task-ping
karena akan dibangun di salah satu gambar, tetapi tanpa membangun sisa demo, jalankan:
$ cargo xtask build app/gimletlet/app.toml ping
clippy
Sub -perintah cargo xtask clippy
dapat digunakan untuk menjalankan clippy
terhadap satu atau lebih tugas dalam konteks gambar tertentu:
$ cargo xtask clippy app/gimletlet/app.toml ping pong
rust-analyzer
Sistem build hubris tidak akan bekerja dengan rust-analyzer
di luar kotak.
Namun, cargo xtask lsp
ada di sini untuk membantu: dibutuhkan sebagai argumennya file karat, dan mengembalikan konfigurasi yang dikodekan JSON untuk cara mengatur rust-analyzer
.
Untuk menggunakan data ini, beberapa konfigurasi editor diperlukan!
(Kami belum membuat plugin, tetapi tentu saja mungkin)
Menggunakan Neovim dan rust-tools
, berikut adalah contoh konfigurasi:
-- monkeypatch rust-tools to correctly detect our custom rust-analyzer
require ' rust-tools.utils.utils ' . is_ra_server = function ( client )
local name = client . name
local target = " rust_analyzer "
return string.sub ( client . name , 1 , string.len ( target )) == target
or client . name == " rust_analyzer-standalone "
end
-- Configure LSP through rust-tools.nvim plugin, with lots of bonus
-- content for Hubris compatibility
local cache = {}
local clients = {}
require ' rust-tools ' . setup {
tools = { -- rust-tools options
autoSetHints = true ,
inlay_hints = {
show_parameter_hints = false ,
parameter_hints_prefix = " " ,
other_hints_prefix = " " ,
-- do other configuration here as desired
},
},
server = {
on_new_config = function ( new_config , new_root_dir )
local bufnr = vim . api . nvim_get_current_buf ()
local bufname = vim . api . nvim_buf_get_name ( bufnr )
local dir = new_config . root_dir ()
if string.find ( dir , " hubris " ) then
-- Run `xtask lsp` for the target file, which gives us a JSON
-- dictionary with bonus configuration.
local prev_cwd = vim . fn . getcwd ()
vim . cmd ( " cd " .. dir )
local cmd = dir .. " /target/debug/xtask lsp "
-- Notify `xtask lsp` of existing clients in the CLI invocation,
-- so it can check against them first (which would mean a faster
-- attach)
for _ , v in pairs ( clients ) do
local c = vim . fn . escape ( vim . json . encode ( v ), ' " ' )
cmd = cmd .. ' -c" ' .. c .. ' " '
end
local handle = io.popen ( cmd .. bufname )
handle : flush ()
local result = handle : read ( " *a " )
handle : close ()
vim . cmd ( " cd " .. prev_cwd )
-- If `xtask` doesn't know about `lsp`, then it will print an error to
-- stderr and return nothing on stdout.
if result == " " then
vim . notify ( " recompile `xtask` for `lsp` support " , vim . log . levels . WARN )
end
-- If the given file should be handled with special care, then
-- we give the rust-analyzer client a custom name (to prevent
-- multiple buffers from attaching to it), then cache the JSON in
-- a local variable for use in `on_attach`
local json = vim . json . decode ( result )
if json [ " Ok " ] ~= nil then
new_config . name = " rust_analyzer_ " .. json . Ok . hash
cache [ bufnr ] = json
table.insert ( clients , { toml = json . Ok . app , task = json . Ok . task })
else
-- TODO:
-- vim.notify(vim.inspect(json.Err), vim.log.levels.ERROR)
end
end
end ,
on_attach = function ( client , bufnr )
local json = cache [ bufnr ]
if json ~= nil then
local config = vim . deepcopy ( client . config )
local ra = config . settings [ " rust-analyzer " ]
-- Do rust-analyzer builds in a separate folder to avoid blocking
-- the main build with a file lock.
table.insert ( json . Ok . buildOverrideCommand , " --target-dir " )
table.insert ( json . Ok . buildOverrideCommand , " target/rust-analyzer " )
ra . cargo = {
extraEnv = json . Ok . extraEnv ,
features = json . Ok . features ,
noDefaultFeatures = true ,
target = json . Ok . target ,
buildScripts = {
overrideCommand = json . Ok . buildOverrideCommand ,
},
}
ra . check = {
overrideCommand = json . Ok . buildOverrideCommand ,
}
config . lspinfo = function ()
return { " Hubris app: " .. json . Ok . app ,
" Hubris task: " .. json . Ok . task }
end
client . config = config
end
end ,
settings = {
[ " rust-analyzer " ] = {
-- enable clippy on save
checkOnSave = {
command = " clippy " ,
extraArgs = { ' --target-dir ' , ' target/rust-analyzer ' },
},
diagnostics = {
disabled = { " inactive-code " },
},
}
}
},
}
end
Ketika konfigurasi LSP baru dibuat ( on_new_config
), kami menjalankan cargo xtask lsp
pada file target. Konfigurasi JSON mencakup hash dari konfigurasi; Kami menggunakan hash itu untuk memodifikasi nama klien dari rust_analyzer
ke rust_analyzer_$HASH
. Ini mencegah Neovim mencoba menggunakan kembali klien yang sudah ada, yang biasanya dideduplikasi oleh nama klien dan direktori root ruang kerja; Di Hubris, kami ingin beberapa klien hidup berdampingan dengan root ruang kerja yang sama, sehingga mereka membutuhkan nama yang berbeda. Kemudian, kami menyimpan sisa konfigurasi dalam variabel lokal ( cache
), dan mencatat keberadaan klien ini pada clients
.
Saat melekat pada LSP, kami mencoba menarik konfigurasi dari cache
. Jika ada, maka kita tahu kita berurusan dengan buffer keangkuhan; Salin bagian konfigurasi yang relevan.
Perhatikan bahwa ini tidak menyusun xtask
untuk Anda; Diasumsikan sudah ada di target/debug/xtask
. Ini harus benar jika Anda menggunakan keangkuhan secara teratur, dan menghemat banyak waktu saat membuka file baru.
Untuk membuat tugas Anda sendiri, metode termudah adalah:
task/template
ke nama baru.Cargo.toml
dengan nama Anda dan nama paket baru.Cargo.toml
.app.toml
.cargo xtask build
untuk mengkompilasinya. Entri app.toml
yang khas untuk tugas kecil yang tidak menggunakan periferal yang dipetakan memori akan dibaca
[ tasks . name_for_task_in_this_image ]
name = " my-task-target-name "
priority = 1
requires = { flash = 1024 , ram = 1024 }
start = true
Grafik dapat dihasilkan yang menunjukkan hubungan berbagai tugas dan prioritasnya. File yang dihasilkan ada dalam format dot
GraphViz. Sumber Dot
dapat dimasukkan dalam sumber asciidoctor atau diterjemahkan ke berbagai format.
Untuk membuat dan melihat grafik SVG untuk gimletlet
di Ubuntu, pastikan paket graphviz
diinstal. Kemudian hasilkan grafik:
$ cargo xtask graph -o gimletlet.dot app/gimletlet/app.toml
$ dot -Tsvg gimletlet.dot > gimletlet.svg
$ xdg-open gimletlet.svg
Perintah bash untuk menghasilkan semua grafik:
APPS=( $(find app -name '*.toml' ! -name Cargo.toml) )
for app in "${APPS[@]}"
do
out=$(basename ${app////_} .toml).dot
svg=$(basename $out .dot).svg
cargo xtask graph -o $out $app
dot -Tsvg $out > $svg
done
first="${APPS[0]}"
out="$(basename ${first////_} .toml).dot"
svg="$(basename $out .dot).svg"
xdg-open "${svg}"
Jika eog
adalah penampil default, membuka SVG pertama di direktori akan memungkinkan bersepeda melalui semua grafik yang tersedia menggunakan jendela yang sama.
Hubris secara ketat digabungkan dengan debuggernya, kerendahan hati, yang digunakan untuk perintah di bawah ini baik secara implisit (dalam cargo xtask flash
) atau secara eksplisit (dalam cargo xtask humility
).
Jika biner humility
tidak tersedia di $PATH
Anda, variabel lingkungan HUBRIS_HUMILITY_PATH
dapat digunakan untuk menyediakan jalur ke biner.
Gambar dalam arsip hubris dapat dilontarkan langsung ke papan target dengan menjalankan cargo xtask flash
dan menentukan file TOML yang sesuai. Ini akan menjalankan cargo xtask dist
dan kemudian melewati arsip build ke humility flash
. humility
akan memohon OpenOCD atau Pyocd untuk mem -flash gambar; Doa yang tepat tergantung pada papan dan dikodekan dalam arsip build.
cargo xtask flash app/lpc55xpresso/app.toml
cargo xtask flash app/demo-stm32f4-discovery/app.toml
cargo xtask flash app/demo-stm32h7-nucleo/app-h743.toml
cargo xtask flash app/demo-stm32h7-nucleo/app-h753.toml
cargo xtask flash app/gemini-bu/app.toml
Kerendahan hati dijalankan in situ dengan menentukan arsip pada papan yang terhubung langsung, atau postmortem dengan menentukan tempat pembuangan. Sebagai kenyamanan untuk pengembangan, kerendahan hati juga dapat dijalankan secara in situ dengan menentukan TOML yang sesuai, misalnya pada mesin dengan papan penemuan STM32F4 secara langsung terpasang:
$ cargo xtask humility app/demo-stm32f4-discovery/app.toml -- tasks
Finished dev [optimized + debuginfo] target(s) in 0.17s
Running `target/debug/xtask humility demo/app.toml -- tasks`
humility: attached via ST-Link
ID ADDR TASK GEN STATE
0 20000108 jefe 0 Healthy(InRecv(None))
1 20000178 rcc_driver 0 Healthy(InRecv(None))
2 200001e8 usart_driver 0 Healthy(InRecv(None))
3 20000258 user_leds 0 Healthy(Runnable) <-
4 200002c8 ping 48 Healthy(Runnable)
5 20000338 pong 0 Healthy(InRecv(None))
6 200003a8 idle 0 Healthy(Runnable)
humility
mencakup subkomand gdb
yang melekat pada sistem yang berjalan menggunakan arm-none-eabi-gdb
, secara opsional menjalankan instance openocd
sendiri berdasarkan data konfigurasi di arsip Build.
Untuk kenyamanan, ada juga façade cargo xtask gdb
yang menyebut humility
dengan arsip build yang sesuai:
$ cargo xtask gdb app/demo-stm32f4-discovery/app.toml -- --run-openocd
# ... lots of output elided ...
task_idle::main () at task/idle/src/main.rs:14
14 loop {
Breakpoint 1 at 0x800434c: file /crates.io/cortex-m-rt-0.6.15/src/lib.rs, line 560.
Note: automatically using hardware breakpoints for read-only addresses.
semihosting is enabled
semihosting is enabled
(gdb)
Perhatikan bahwa cargo xtask gdb
akan (secara default) juga menjalankan dist
and flash
, untuk memastikan bahwa gambar pada chip terbaru. Opsi -n
/ --noflash
melewatkan langkah -langkah ini.
Kernel keangkuhan diuji dengan gambar uji khusus yang mencakup pelari uji, asisten dan test suite. Gambar uji memancarkan hasilnya melalui ITM. Sementara hasil ini dapat ditafsirkan secara manual, humility test
mengotomatiskan ini. humility test
itu sendiri paling mudah dijalankan melalui cargo xtask test
, yang menjalankan setara dengan cargo xtask dist
, cargo xtask flash
dan cargo xtask humility test
. Doa yang tepat tergantung pada papan:
cargo xtask test test/tests-lpc55xpresso/app.toml
cargo xtask test test/tests-stm32fx/app-f3.toml
cargo xtask test test/tests-stm32fx/app.toml
cargo xtask test test/tests-stm32h7/app-h743.toml
cargo xtask test test/tests-stm32h7/app-h753.toml
Catatan: cargo xtask humility test
menjalankan OpenOCD untuk terhubung ke perangkat. Anda harus keluar dari contoh lain OpenOCD yang telah Anda hubungkan ke perangkat sebelum menjalankan tes.
Lihat Dokumentasi untuk humility test
untuk detail tentang hasil tes.
Output dari tes ditangkap oleh humility test
; sys_log!()
Panggilan ke tes dapat ditambahkan dan kemudian ditangkap dalam pembuangan humility test
. Untuk menangkap dump dari tes yang lewat, gunakan cargo xtask humility
secara langsung dan lulus bendera -d
, misalnya:
$ cargo xtask humility test/tests-stm32fx/app.toml -- test -d
...
humility: attached via ST-Link
humility: TPIU sync packet found at offset 1
humility: ITM synchronization packet found at offset 12
humility: expecting 22 cases
humility: running test_send ... ok
...
humility: running test_timer_notify ... ok
humility: running test_timer_notify_past ... ok
humility: tests completed: pass
humility: test output dumped to hubris.testout.2
Jika seseorang perlu menjalankan GDB dan test suite, gunakan cargo xtask gdb
dengan TOML tes gambar dan file GDB yang sesuai, dan kemudian tempatkan breakpoint pada tes minat.
Lihat Gemini Membawa Memulai Dokumen (Repo Oksida Internal)
Untuk papan penemuan STM32F3, SB10 harus disolder ditutup agar ITM bekerja! Jembatan solder ini default untuk dibuka, yang membuat SWO terputus. Lihat Manual Pengguna Penemuan STM32F3 (UM1570) untuk skema dan detail.
Untuk menggunakan LPCXPRESSO55S69, Anda akan memerlukan Pyocd, versi 0.27.0 atau lebih baru.
LPCXPRESSO55S69 agak berantakan karena debugger on-chip yang dibangun, LPC-Link2, tidak mendukung dengan benar SWO/SWV
Jika Anda memiliki stok LPC-Link2, itu akan melaporkan dirinya dengan cara ini melalui pyocd list
:
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------
0 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.361 JSAQCQIQ
Mungkin juga Anda memiliki firmware Segger J-Link-firmware yang akan membuat kehadirannya yang menjijikkan dikenal dengan meminta Anda menerima syarat lisensi setiap kali menjalankan pyocd list
!
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------------------
0 Segger J-Link LPCXpresso V2 compiled Apr 4 2019 16:54:03 726424936
Dalam salah satu dari kasus ini, Anda harus-sebagai langkah satu kali-menginstal firmware baru di LPC-Link2. Firmware baru adalah build dari Daplink (open source), yang kami sebut Ricklink setelah insinyur yang berhasil membangun semuanya - bukan prestasi kecil!
Ada dua file yang Anda butuhkan, keduanya terkandung dalam repositori hubris:
Anda juga membutuhkan program LPCScrypt dari NXP.
Berikut adalah langkah -langkah untuk menginstal Ricklink:
Pasang jumper DFU. Ini dapat ditemukan di sebelah header SWD di sisi kiri papan; itu diberi label "DFU".
Jalankan scripts/boot_lpcscrypt
dari perangkat lunak LPCScrypt yang diinstal:
$ /usr/local/lpcscrypt/scripts/boot_lpcscrypt
Looking for DFU devices with VID 1fc9 PID 000c ...
dfu-util -d 1fc9:000c -c 1 -i 0 -t 2048 -R -D /usr/local/lpcscrypt/scripts/../bin/LPCScrypt_228.bin.hdr
Booted LPCScrypt target (1fc9:000c) with /usr/local/lpcscrypt/scripts/../bin/LPCScrypt_228.bin.hdr
$
lpcscrypt clockslow
: $ /usr/local/lpcscrypt/bin/lpcscrypt clockslow
$
lpcscrypt program +w1 0x0 BankA
untuk menimpa firmware yang ada $ /usr/local/lpcscrypt/bin/lpcscrypt program +w1 0x0 BankA
................
Programmed 524288 bytes to 0x1a000000 in 2.610s (196.165KB/sec)
$
lpcscrypt program +c <path-to-lpc4322_bl_crc.bin> BankA
: $ /usr/local/lpcscrypt/bin/lpcscrypt program +c ~ /hubris/support/lpc4322_bl_crc.bin BankA
..
Programmed 57344 bytes to 0x1a000000 in 0.827s (67.717KB/sec)
$
Dengan asumsi itu berhasil, lepaskan jumper DFU dan lepaskan/sambungkan kembali USB
Sekarang harus ada perangkat penyimpanan massal USB bernama MAINTENANCE
# fdisk -l
Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Micron 2200S NVMe 512GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A8653F99-39AB-4F67-A9C9-524A2864856E
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 967393279 966342656 460.8G Linux filesystem
/dev/nvme0n1p3 967393280 1000214527 32821248 15.7G Linux swap
Disk /dev/sda: 64.1 MiB, 67174400 bytes, 131200 sectors
Disk model: VFS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
# mount /dev/sda /mnt
# ls /mnt
DETAILS.TXT PRODINFO.HTM
# cat /mnt/DETAILS.TXT
# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 02360b000d96e4fc00000000000000000000000097969905
HIC ID: 97969905
Auto Reset: 1
Automation allowed: 1
Overflow detection: 1
Daplink Mode: Interface
Interface Version: 0254
Bootloader Version: 0254
Git SHA: f499eb6ec4a847a2b78831fe1acc856fd8eb2f28
Local Mods: 1
USB Interfaces: MSD, CDC, HID, WebUSB
Bootloader CRC: 0x09974fb3
Interface CRC: 0x7174ab4c
Remount count: 0
URL: https://os.mbed.com/platforms/LPCXpresso55S69/
lpc4322_lpc55s69xpresso_if_rla_swo_hacks.bin
ke drive usb $ sudo cp ~ /hubris/support/lpc4322_lpc55s69xpresso_if_rla_swo_hacks.bin /mnt
$
# umount /mnt
#
Verifikasi bahwa Anda berada di firmware baru dengan menjalankan pyocd list
:
$ pyocd list
# Probe Unique ID
-------------------------------------------------------------------------------------
0 LPCXpresso55S69 [lpc55s69] 02360b000d96e4fc00000000000000000000000097969905
Perhatikan bahwa becak yang berjalan pada LPCXPresso55S69 juga dapat digunakan sebagai debugger untuk LPC55S28 di papan pembawa Gemini. Untuk melakukan ini, pertama -tama, ikuti semua instruksi di atas untuk mendapatkan beku ke LPCXPresso55S69 Anda. Kemudian:
Menggunakan besi solder, solder tajuk dua pin pada J5. J5 dapat ditemukan di sebelah kiri P1 dan di bawah jumper "debugger" (J3).
Letakkan jumper di header baru
Pindahkan jumper "debugger" (j3) ke "ext".
Gunakan kabel SWD (kabel pitch 10-pin 2x5 1.27mm) untuk menghubungkan SWD pada LPCXPRESSO55S69 ke SWD di bawah papan operator di Gemini (J202)
(Untuk memungkinkan beku Anda sekali lagi men -debug LPC55S69 lokal, lepaskan jumper pada J5 dan pindahkan J3 ke "loc".)
Jika beberapa probe terpasang, alat mungkin berjuang untuk menemukan yang tepat pada waktu yang tepat. Secara khusus, OpenOCD akan memilih yang pertama yang ditemukannya; Untuk memaksa OpenOCD untuk memilih probe tertentu , Anda dapat memastikan nomor seri probe (misalnya, dari humility probe
) dan kemudian menentukan nomor seri itu dalam openocd.cfg
yang sesuai dengan menambahkan, misalnya:
interface hla
hla_serial 271828182845904523536028
(Di mana 271828182845904523536028
adalah nomor seri probe.)
Adalah umum bahwa debugging dongles, dan papan pengembangan dengan perangkat keras debug tertanam seperti seri Nucleo, dikirimkan dengan firmware yang lebih lama.
Anda tidak akan dapat menggunakan humilty dengan firmware st-link yang sudah ketinggalan zaman. Kerendahan hati akan memberi tahu Anda bahwa ini adalah masalahnya, misalnya ketika mencoba menggunakan humility test
:
...
Warn : Adding extra erase range, 0x08020060 .. 0x0803ffff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
humility: test failed: The firmware on the probe is outdated
Error: test failed
Ikuti tautan "St-Link Firmware Upgrade" ini untuk menemukan perangkat lunak dan instruksi yang diperlukan untuk menginstal firmware saat ini.