hubris
sidecar release
Hybris ist eine mikrocontroller Betriebsumgebung für tief eingebettete Systeme mit Zuverlässigkeitsanforderungen. Sein Design wurde zunächst in RFD41 vorgeschlagen, hat sich jedoch seitdem erheblich weiterentwickelt.
Die Entwicklerdokumentation befindet sich im doc/ Verzeichnis in Asciidoc. Es wird über Github -Seiten gerendert und ist unter https://oxidecomputer.github.io/hubris erhältlich.
Das Repo ist wie folgt ausgelegt.
app/ ist dort, wo die Binärkisten der obersten Ebene für Anwendungen live, z. B. app/gimlet die Firmware-Kiste für Gimlet enthält. Wenn Sie ein Bild für etwas erstellen möchten, schauen Sie hier im Allgemeinen hier.
build/ Enthält das Build -System und die unterstützenden Kisten.
chip/ enthält periphere Definitionen und Debugging -Support -Dateien für einzelne Mikrocontroller.
doc/ Enthält Entwicklerdokumentation.
drv/ enthält Treiber, eine Mischung aus einfachen Treiber-Lib-Kisten und vollwertigen Server-Bin-Kisten. Aktuelle Konvention ist, dass drv/SYSTEM-DEVICE der Treiber für DEVICE auf SYSTEM ist (wobei SYSTEM normalerweise ein SoC-Name ist), während drv/SYSTEM-DEVICE-server die Server-Bincrate ist.
idl/ enthält Schnittstellendefinitionen, die in Idol geschrieben wurden
lib/ enthält verschiedene Dienstprogrammbibliotheken, die wir geschrieben haben. Wenn Sie eine wiederverwendbare Kiste erstellen müssen, die nicht in eines der anderen Verzeichnisse passt, gehört sie wahrscheinlich hierher.
stage0/ ist der Bootloader/ Hypovisor, vor allem für LPC55.
support/ Enthält einige Schnittstellen- und Programmierunterstützungsdateien wie gefälschte Zertifikate und Programmierer -Firmware -Bilder.
sys/ enthält die "System" -Hubris, nämlich den Kernel ( sys/kern ), die gemeinsame Kiste, die das ABI ( sys/abi ) definiert, und die von Aufgaben verwendete Benutzerbibliothek ( sys/userlib ).
task/ enthält wiederverwendbare Aufgaben, die keine Treiber sind. Die Unterscheidung zwischen Dingen, die in task und in drv/something-server leben, ist unscharf. Verwenden Sie Ihr Urteilsvermögen.
test/ Enthält das Testgerüst und binäre Kisten für den Bau für verschiedene Boards.
website/ enthält den Quellcode für die Hybris -Website
Wir unterstützen derzeit Linux und Windows als Erststufe-Plattformen. MacOS wird auch täglich von Oxide -Mitarbeitern verwendet, aber in CI nicht getestet. Der Build funktioniert wahrscheinlich auch auf Illumos; Wenn jemand auftreten möchte, um Unterstützung und einen kontinuierlichen Build für Illumos oder MacOS aufrechtzuerhalten, würden wir die Hilfe lieben.
Um Änderungen zur Überprüfung einzureichen, drücken Sie sie in eine Zweigstelle in einer Gabel und senden Sie eine Pull -Anfrage, um diese Filiale in master zu verschmelzen. Weitere Informationen finden Sie CONTRIBUTING.md .
Sie brauchen:
Eine rustup -Basis -Toolchain -Installation. rustup kümmert sich um die automatische Installation unserer festgestellten Toolchain-Version und die Cross-Compilation-Ziele, wenn Sie zum ersten Mal versuchen zu bauen.
openocd (idealerweise 0,11) oder (bei Verwendung des LPC55) pyocd (0,27 oder später). Beachten Sie, dass die 0,10 -Freisetzung von OpenOCD vor dem STLink V3 vorliegt. Die Leute verwenden verschiedene nach 0,10, vor 0.11 von Systempaketmanagern bereitgestellte Erstellungen vor 0.10 Uhr, aber wenn Ihr System noch nicht 0,11 verpackt ist, belästigen Sie sie. Wenn Sie Homebrew auf MacOS verwenden, um OpenOCD zu installieren, müssen Sie brew install --head openocd verwenden, um die Spitze der Hauptzweig zu erstellen, anstatt die neueste Binärveröffentlichung zu verwenden. Wenn Sie aus der Quelle erstellen müssen, finden Sie hier OpenOCD v0.11.0. Stellen ST-Link Programmer beim ./configure .
Libusb, in der Regel aus dem Paketmanager Ihres Systems als libusb-1.0.0 oder ähnlich.
libfdti1, als libftdi1-dev oder ähnlich gefunden.
Wenn Sie GDB ausführen, sollten Sie arm-none-eabi-gdb installieren. Dies erfolgt in der Regel aus dem Paketmanager Ihres Systems mit einem Paketnamen wie arm-none-eabi-gdb oder gdb-multiarch . MacOS-Benutzer können brew install --cask gcc-arm-embedded um die offiziellen ARM-Binärdateien zu installieren.
Der Hybris -Debugger, Demut. Beachten Sie, dass cargo install seltsamerweise mit der im Stamm dieses Repository vorhandenen rust-toolchain.toml Datei interagiert. Wenn Sie den folgenden Befehl wörtlich ausführen, um Demut zu installieren, tun Sie dies aus einem anderen Verzeichnis:
cargo install --git https://github.com/oxidecomputer/humility.git --locked humilitycargo-readme als Abhängigkeit: cargo install cargo-readmeEs gibt drei alternative Möglichkeiten zur Installation von OpenOCD:
Hier finden Sie hier, dass Sie die Quelle von openocd erhalten oder inoffizielle Binärdateien erhalten.
Alternativ können Sie mit Schokoladen installieren:
> choco install openocd Zuletzt können Sie openocd mit Scoop installieren:
> scoop bucket add extras
> scoop install openocd Hinweis: openocd das über scoop installiert wurde, hat sich für einige Benutzer als problematisch erwiesen. Wenn Sie Probleme haben, versuchen Sie, über choco oder aus Quelle (siehe oben) zu installieren.
Um den ST-Link-Programmierer zu verwenden, müssen Sie diesen Treiber wahrscheinlich installieren.
Es ist nicht notwendig, Hybris zu bauen und auszuführen, aber wenn Sie über einen seriellen Link kommunizieren möchten (und das wird nicht von Ihrem Terminal unterstützt), möchten Sie Putty verwenden. Dieser Leitfaden erklärt gut, wie.
Wir verwenden keinen cargo build oder cargo run , weil sie für unsere Zwecke zu unflexibel sind. Wir haben einen komplexen Multi-Architektur-Build, der ein bisschen über sie hinausgeht.
Stattdessen enthält das Repo eine Frachtverlängerung namens xtask , die unsere benutzerdefinierten Build -Befehle namensspasiert.
cargo xtask dist TOMLFILE erstellt ein Verteilungsbild für die von der TOML -Datei beschriebene Anwendung.
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 - LPCXPRESO55S69cargo 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 - Gemini Bringup Board Da ein vollständiger Bildbau 10 Sekunden oder mehr dauern kann, je nachdem, was Sie sich geändert haben, möchten Sie es wahrscheinlich separat erstellen. Dafür ist cargo xtask build da.
Zum Beispiel zum Aufbau task-ping , die in einem der Bilder eingebaut werden würden, ohne den Rest der Demo zu bauen, rennen Sie:
$ cargo xtask build app/gimletlet/app.toml ping clippy Mit dem cargo xtask clippy können clippy gegen eine oder mehrere Aufgaben ausführen:
$ cargo xtask clippy app/gimletlet/app.toml ping pong rust-analyzer Das Hybris Build-System funktioniert nicht mit rust-analyzer aus der Schachtel.
cargo xtask lsp ist jedoch hier, um zu helfen: Es dauert als Argument eine Rust-Datei und gibt die JSON-kodierte Konfiguration zurück, um rust-analyzer einzurichten.
Um diese Daten zu verwenden, ist eine gewisse Editorkonfiguration erforderlich!
(Wir haben noch keine Plugins gemacht, aber es wäre sicherlich möglich)
Mit Neovim und rust-tools finden Sie hier eine Beispielkonfiguration:
-- 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 Wenn eine neue LSP -Konfiguration erstellt wird ( on_new_config ), führen wir cargo xtask lsp in der Zieldatei aus. Die JSON -Konfiguration enthält einen Hash der Konfiguration. Wir verwenden diesen Hash, um den Namen des Clients von rust_analyzer zu rust_analyzer_$HASH zu ändern. Dies verhindert, dass Neovim versucht, einen bestehenden Mandanten wiederzuverwenden, der normalerweise mit dem Kundennamen und dem Arbeitsbereich Root Directory bestimmt wird. In Hybris möchten wir mehrere Clients, die mit derselben Arbeitsbereichswurzel koexistieren, sodass sie unterschiedliche Namen benötigen. Dann verstauen wir den Rest der Konfiguration in einer lokalen Variablen ( cache ) und zeichnen die Existenz dieses Kunden in clients auf.
Beim Anbringen am LSP versuchen wir, die Konfiguration aus cache herauszuholen. Wenn einer existiert, wissen wir, dass wir es mit einem Hybris -Puffer zu tun haben. Kopieren Sie über relevante Teile der Konfiguration.
Beachten Sie, dass dies nicht xtask für Sie kompiliert wird. Es wird davon ausgegangen, dass es bereits in target/debug/xtask existiert. Dies sollte wahr sein, wenn Sie Hubris regelmäßig verwenden und beim Öffnen einer neuen Datei erhebliche Zeit sparen.
Um Ihre eigene Aufgabe zu erstellen, ist die einfachste Methode:
task/template in einen neuen Namen.Cargo.toml mit Ihrem Namen und einem neuen Paketnamen.Cargo.toml hinzu.app.toml -Datei bearbeiten.cargo xtask build aus, um es zu kompilieren. Ein typischer app.toml Eintrag für eine kleine Aufgabe, bei der keine peripheren Speicherverpackungen verwendet werden
[ tasks . name_for_task_in_this_image ]
name = " my-task-target-name "
priority = 1
requires = { flash = 1024 , ram = 1024 }
start = true Es kann ein Diagramm erstellt werden, das die Beziehungen der verschiedenen Aufgaben und ihrer Prioritäten zeigt. Die resultierende Datei befindet sich im dot -Format von GraphViz. Dot -Quelle kann in der Asciidoctor -Quelle aufgenommen oder einer Vielzahl von Formaten gerendert werden.
Stellen Sie sicher, dass das graphviz -Paket installiert ist, um ein SVG -Diagramm für gimletlet auf Ubuntu zu erstellen und anzuzeigen. Generieren Sie dann die Grafik:
$ cargo xtask graph -o gimletlet.dot app/gimletlet/app.toml
$ dot -Tsvg gimletlet.dot > gimletlet.svg
$ xdg-open gimletlet.svgBash -Befehle, um alle Grafiken zu generieren:
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}" Wenn eog der Standard -Viewer ist, ermöglicht das Öffnen des ersten SVG in einem Verzeichnis das Radfahren durch alle verfügbaren Diagramme mit demselben Fenster.
Hybris ist eng mit seinem Debugger, Demut, gekoppelt, der für die folgenden Befehle entweder implizit (in cargo xtask flash ) oder explizit (in cargo xtask humility ) verwendet wird.
Wenn die humility -Binärdatei auf Ihrem $PATH nicht verfügbar ist, kann die Umgebungsvariable HUBRIS_HUMILITY_PATH verwendet werden, um den Pfad zum Binary bereitzustellen.
Ein Bild in einem Hybris -Archiv kann direkt auf eine Zielplatine geblitzt werden, indem cargo xtask flash und die entsprechende TOML -Datei angegeben werden. Dadurch wird cargo xtask dist ausgeführt und dann das resultierende Build -Archiv an humility flash übergeben. humility ruft entweder OpenOCD oder Pyocd auf, um das Bild zu blinken. Der genaue Aufruf hängt vom Board ab und wird im Build -Archiv codiert.
cargo xtask flash app/lpc55xpresso/app.tomlcargo xtask flash app/demo-stm32f4-discovery/app.tomlcargo xtask flash app/demo-stm32h7-nucleo/app-h743.tomlcargo xtask flash app/demo-stm32h7-nucleo/app-h753.tomlcargo xtask flash app/gemini-bu/app.toml Demut wird in situ durchgeführt, indem ein Archiv auf einem direkt angeschlossenen Board oder postmortem angegeben wird, indem ein Müllkippe angegeben wird. Als Komfort für die Entwicklung kann Demut auch in situ durchgeführt werden, indem das entsprechende TOML angegeben wird, z. B. auf einer Maschine mit einem direkt angeschlossenen STM32F4 -Erkennungsfeld:
$ 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 umfasst einen gdb Unterbefehl, der mit arm-none-eabi-gdb an ein laufendes System angeschlossen wird und optional eine eigene openocd -Instanz basierend auf Konfigurationsdaten im Build-Archiv ausführt.
Aus Gründen der Bequemlichkeit gibt es auch eine cargo xtask gdb , die humility mit dem entsprechenden Build -Archiv bezeichnet:
$ 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) Beachten Sie, dass cargo xtask gdb (standardmäßig) auch dist und flash ausführen wird, um sicherzustellen, dass das Bild auf dem Chip auf dem neuesten Stand ist. Die Option -n / --noflash -Option überspringt diese Schritte.
Der Hybris -Kernel wird mit einem speziellen Testbild getestet, das einen Testläufer, Assistenten und Testsuite enthält. Das Testbild gibt seine Ergebnisse über ITM ab. Während diese Ergebnisse manuell interpretiert werden können, automatisiert humility test dies. humility test selbst ist am einfachsten über cargo xtask test durchzuführen, der das Äquivalent zu cargo xtask dist , cargo xtask flash und cargo xtask humility test ausführt. Der genaue Aufruf hängt vom Board ab:
cargo xtask test test/tests-lpc55xpresso/app.tomlcargo xtask test test/tests-stm32fx/app-f3.tomlcargo xtask test test/tests-stm32fx/app.tomlcargo xtask test test/tests-stm32h7/app-h743.tomlcargo xtask test test/tests-stm32h7/app-h753.toml HINWEIS: cargo xtask humility test wird OpenOCD ausgeführt, um eine Verbindung zum Gerät herzustellen. Sie müssen alle anderen Instanzen von OpenOCD verlassen, die Sie vor dem Ausführen von Tests mit dem Gerät angeschlossen haben.
Weitere Informationen zu den Testergebnissen finden Sie in der Dokumentation für humility test .
Die Ausgabe von Tests wird durch humility test erfasst. sys_log!() Aufrufe zu Tests können hinzugefügt und dann in einem humility test -Dump erfasst werden. Um einen Müllkippe aus Tests zu erfassen, die ansonsten bestanden werden, verwenden Sie cargo xtask humility direkt und bestehen Sie die -d -Flag, z. B.:
$ 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 Wenn Sie sowohl GDB als auch die Testsuite ausführen müssen, verwenden Sie cargo xtask gdb mit dem TOML des Testbildes und der entsprechenden GDB -Datei und platzieren Sie dann den Breakpoints zum Test von Interesse.
Sehen Sie sich die Gemini -Bringup -Erste Schritte an Docs (internes Oxid -Repo).
Für das STM32F3 Discovery Board muss SB10 für die Arbeit gelötet werden! Diese Lötbrücke wird in Verzug gebracht, um offen zu sein, wodurch die SWO getrennt werden. Schema und Details finden Sie im STM32F3 Discovery -Benutzerhandbuch (UM1570).
Um den LPCXpression55S69 zu verwenden, benötigen Sie Pyocd, Version 0.27.0 oder höher.
Der LPCXpressO55S69 ist ein Chaos, da der integrierte On-Chip-Debugger LPC-Link2 SWO/SWV nicht richtig unterstützt
Wenn Sie die Aktien-LPC-Link2 haben, meldet sie sich auf diese Weise über pyocd list :
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------
0 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.361 JSAQCQIQ Es ist auch möglich, dass Sie die Segger J-Link-Firmware haben-Firmware, die ihre abscheuliche Präsenz durch die Aufforderung zur Annahme von Lizenzbedingungen beim Ausführen von pyocd list macht!
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------------------
0 Segger J-Link LPCXpresso V2 compiled Apr 4 2019 16:54:03 726424936In beiden Fällen müssen Sie-als einmaliger Schritt-neue Firmware auf dem LPC-Link2 installieren. Die neue Firmware ist ein Aufbau des (Open Source) Daplink , den wir nach dem Ingenieur, der es geschafft hat, alles zu bauen, liebevoll nennen - keine kleine Leistung!
Es gibt zwei Dateien, die Sie benötigen, die beide im Hybris -Repository enthalten sind:
Sie benötigen außerdem das LPCScrypt -Programm von NXP.
Hier sind die Schritte zur Installation von Ricklink:
Installieren Sie den DFU -Jumper. Dies kann neben dem SWD -Header auf der linken Seite des Bretts gefunden werden. Es ist als "DFU" bezeichnet.
Führen Sie scripts/boot_lpcscrypt aus der installierten LPCScrypt -Software aus:
$ /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 aus: $ /usr/local/lpcscrypt/bin/lpcscrypt clockslow
$lpcscrypt program +w1 0x0 BankA aus, um vorhandene Firmware zu überschreiben $ /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 aus: $ /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)
$Angenommen, es ist erfolgreich, entfernen Sie den DFU -Pullover und trennen Sie USB und verbinden Sie sie wieder an.
Es sollte jetzt ein USB -Massenspeichergerät mit dem Namen MAINTENANCE geben
# 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 $ sudo cp ~ /hubris/support/lpc4322_lpc55s69xpresso_if_rla_swo_hacks.bin /mnt
$# umount /mnt
# Stellen Sie sicher, dass Sie sich auf der neuen Firmware befinden, indem Sie pyocd list ausführen:
$ pyocd list
# Probe Unique ID
-------------------------------------------------------------------------------------
0 LPCXpresso55S69 [lpc55s69] 02360b000d96e4fc00000000000000000000000097969905 Beachten Sie, dass der Ricklink auf dem LPCXpressO55S69 auch als Debugger für den LPC55S28 auf der Gemini Carrier Board verwendet werden kann. Befolgen Sie zuerst alle obigen Anweisungen, um Ricklink auf Ihren LPCXPressO55S69 zu bringen. Dann:
Löten Sie mit einem Lötkolben einen Zwei-Pol-Header auf J5. J5 kann links von P1 und unterhalb des "Debugger" -Pulpers (J3) gefunden werden.
Setzen Sie einen Springer auf den neuen Kopfball
Bewegen Sie den "Debugger" -Pulper (J3) in "ext".
Verwenden Sie ein SWD-Kabel (10-polige 2x5 1,27 mm Pitch-Kabel), um die SWD am LPCXPressO55S69 an die SWD unter der Trägerplatte auf Gemini (J202) anzuschließen.
(Damit Ihr Ricklink erneut seinen lokalen LPC55S69 -Debuggen debuggen, entfernen Sie den Jumper auf J5 und bewegen Sie J3 auf "loc".)
Wenn mehrere Sonden angehängt sind, können Tools Schwierigkeiten haben, zum richtigen Zeitpunkt die richtige zu finden. Insbesondere wird OpenOCD den ersten auswählen, den es findet; Um OpenoCD zur Auswahl einer bestimmten Sonde zu zwingen, können Sie die serielle Anzahl der Sonde (z. B. aus humility probe ) ermitteln und diese serielle Zahl in den entsprechenden openocd.cfg durch Hinzufügen, z. B.:
interface hla
hla_serial 271828182845904523536028
(Wobei 271828182845904523536028 die Seriennummer der Sonde ist.)
Es ist üblich, dass das Debuggen von Donglieren und Entwicklungsbretter mit eingebetteten Debug -Hardware wie der Nucleo -Serie mit älterer Firmware geliefert werden.
Sie werden mit veralteten ST-Link-Firmware nicht in der Lage sein. Demut wird Ihnen sagen, dass dies der Fall ist, beispielsweise beim Versuch, humility test zu verwenden:
...
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
Befolgen Sie diesen Link "ST-Link-Firmware-Upgrade", um Software und Anweisungen zu finden, die zur Installation der aktuellen Firmware erforderlich sind.
