hubris
sidecar release
Hubris est un environnement de fonctionnement de microcontrôleur conçu pour les systèmes profondément emballés avec des exigences de fiabilité. Sa conception a été initialement proposée dans RFD41, mais a évolué considérablement depuis lors.
La documentation du développeur est dans ASCIIDOC dans le répertoire doc/ . Il est rendu via des pages GitHub et est disponible sur https://oxidecuter.github.io/hubris.
Le repo est présenté comme suit.
app/ est où les caisses binaires de haut niveau pour Applications Live, par exemple app/gimlet contient la caisse du micrologiciel pour Gimlet. D'une manière générale, si vous voulez créer une image pour quelque chose, regardez ici.
build/ contient le système de construction et les caisses de support.
chip/ Contient des définitions périphériques et des fichiers de support de débogage pour les microcontrôleurs individuels.
doc/ Contient la documentation du développeur.
drv/ Contient des pilotes, un mélange de caisses Lib de pilotes simples et de caisses de bacs de serveur à part entière. La convention actuelle est que drv/SYSTEM-DEVICE est le pilote du DEVICE sur SYSTEM (où SYSTEM est généralement un nom de SOC), tandis que drv/SYSTEM-DEVICE-server est la caisse de bac de serveur.
idl/ contient des définitions d'interface écrites en idole
lib/ contient des bibliothèques d'utilité assorties que nous avons écrites. Si vous avez besoin de faire une caisse réutilisable qui ne rentre pas dans l'un des autres répertoires, il appartient probablement ici.
stage0/ est le chargeur de démarrage / Hypovisor, principalement pour LPC55.
support/ contient des fichiers de support d'interface et de programmation, comme les faux certificats et les images du micrologiciel du programmeur.
sys/ contient les bits "système" de l'orgueil, à savoir le noyau ( sys/kern ), la caisse partagée définissant l'ABI ( sys/abi ) et la bibliothèque d'utilisateurs utilisées par les tâches ( sys/userlib ).
task/ contient des tâches réutilisables qui ne sont pas des pilotes. La distinction entre les choses qui vivent dans task vs dans drv/something-server est floue. Utilisez votre jugement.
test/ contient le cadre de test et les caisses binaires pour la construire pour diverses cartes.
website/ Contient le code source du site Web Hubris
Nous prenons actuellement en charge Linux et Windows en tant que plates-formes de premier niveau. MacOS est également utilisé quotidiennement par les employés d'oxyde, mais n'est pas testé dans CI. La construction fonctionne probablement également sur Illumos; Si quelqu'un souhaitait intensifier le soutien et une construction continue pour Illumos ou MacOS, nous aimerions l'aide.
Pour soumettre des modifications pour examen, poussez-les dans une succursale dans une fourche et soumettez une demande de traction pour fusionner cette branche dans master . Pour plus de détails, voir CONTRIBUTING.md .
Vous aurez besoin:
Installation de la chaîne à outils basée sur rustup . rustup s'occupera de l'installation automatique de notre version de la chaîne d'outils épinglée et des cibles de compilation croisée, lorsque vous essayez d'abord de construire.
openocd (idéalement 0,11) ou (si vous utilisez le LPC55) pyocd (0,27 ou version ultérieure). Notez que la version 0.10 d'OpenOCD est antérieure au STLink V3. Les gens utilisent diverses constructions post-0,10 et pré-0.11 fournies par les gestionnaires de packages de systèmes, avec un certain succès, mais si votre système n'est pas encore en train d'emballer 0.11, harcelez-les. Si vous allez utiliser HomeBrew sur MacOS pour installer OpenOCD, vous devez utiliser brew install --head openocd pour construire la pointe de la branche principale plutôt que d'utiliser la dernière version binaire. Si vous devez construire à partir de Source, vous pouvez trouver OpenOCD v0.11.0 ici. Lors de l'exécution ./configure , assurez-vous de voir que le ST-Link Programmer est défini (ce qui devrait être la valeur par défaut).
Libusb, généralement trouvé à partir du gestionnaire de packages de votre système en tant que libusb-1.0.0 ou similaire.
libfdti1, trouvé comme libftdi1-dev ou similaire.
Si vous exécutez GDB, vous devez installer arm-none-eabi-gdb . Ceci provient généralement du gestionnaire de packages de votre système avec un nom de package comme arm-none-eabi-gdb ou gdb-multiarch . Les utilisateurs de MacOS peuvent exécuter brew install --cask gcc-arm-embedded pour installer les binaires officiels des bras.
Le débogueur de l'orgueil, l'humilité. Notez que cargo install interagit étrangement avec le fichier rust-toolchain.toml présent à la racine de ce référentiel; Si vous exécutez la commande suivante textuellement pour installer l'humilité, faites-le à partir d'un autre répertoire:
cargo install --git https://github.com/oxidecomputer/humility.git --locked humilitycargo-readme comme dépendance: cargo install cargo-readmeIl existe trois autres façons d'installer OpenOCD:
Voir ici pour obtenir la source d' openocd ou obtenir des binaires non officiels.
Alternativement, vous pouvez installer avec chocolaté:
> choco install openocd Enfin, vous pouvez installer openocd avec Scoop:
> scoop bucket add extras
> scoop install openocd Remarque: openocd installé via scoop s'est révélé problématique pour certains utilisateurs. Si vous rencontrez des problèmes, essayez d'installer via choco ou depuis Source (voir ci-dessus).
Pour utiliser le programmeur ST-Link, vous devrez probablement installer ce pilote.
Il n'est pas nécessaire de construire et d'exécuter Hubris, mais si vous souhaitez communiquer sur un lien en série (et ce n'est pas pris en charge par votre terminal), vous voudrez utiliser Putty; Ce guide fait un bon travail pour expliquer comment.
Nous n'utilisons pas cargo build ou cargo run directement car ils sont trop inflexibles pour nos fins. Nous avons une construction multi-architecture complexe, qui les dépasse un peu.
Au lieu de cela, le repo inclut une extension de cargaison appelée xtask qui espace nos commandes de construction personnalisées.
cargo xtask dist TOMLFILE construit une image de distribution pour l'application décrite par le fichier 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 - LPCXPRESSO55S69cargo 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 Apport Board Parce qu'une version complète d'image peut prendre 10 secondes ou plus, selon ce que vous avez changé, lorsque vous itérez sur une tâche ou un noyau, vous voudrez probablement le construire séparément. C'est à cela que sert cargo xtask build .
Par exemple, pour construire task-ping , car elle serait construite dans l'une des images, mais sans construire le reste de la démo, exécutez:
$ cargo xtask build app/gimletlet/app.toml ping clippy La sous-commande cargo xtask clippy peut être utilisée pour exécuter clippy contre une ou plusieurs tâches dans le contexte d'une image particulière:
$ cargo xtask clippy app/gimletlet/app.toml ping pong rust-analyzer Le système de construction de l'orgueil ne fonctionnera pas avec rust-analyzer hors de la boîte.
Cependant, cargo xtask lsp est là pour aider: il prend comme argument un fichier de rouille et renvoie la configuration codée JSON pour configurer rust-analyzer .
Pour utiliser ces données, une configuration d'éditeur est requise!
(Nous n'avons pas encore fait de plugins, mais ce serait certainement possible)
En utilisant Neovim et rust-tools , voici un exemple de configuration:
-- 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 Lorsqu'une nouvelle configuration LSP est créée ( on_new_config ), nous exécutons cargo xtask lsp sur le fichier cible. La configuration JSON comprend un hachage de la configuration; Nous utilisons ce hachage pour modifier le nom du client de rust_analyzer à rust_analyzer_$HASH . Cela empêche Neovim de tenter de réutiliser un client existant, qui est normalement déducteur par le nom du client et le répertoire racine de l'espace de travail; Dans Hubris, nous voulons que plusieurs clients coexistant avec la même racine d'espace de travail, ils ont donc besoin de noms différents. Ensuite, nous rangeons le reste de la configuration dans une variable locale ( cache ) et enregistrons l'existence de ce client chez clients .
Lors de la connexion au LSP, nous essayons de retirer la configuration du cache . Si l'on existe, alors nous savons que nous avons affaire à un tampon d'orgueil; Copiez sur les parties pertinentes de la configuration.
Notez que cela ne xtask pas pour vous; Il suppose qu'il existe déjà dans target/debug/xtask . Cela devrait être vrai si vous utilisez régulièrement Hubris et économise un temps important lors de l'ouverture d'un nouveau fichier.
Pour créer votre propre tâche, la méthode la plus simple est:
task/template sur un nouveau nom.Cargo.toml avec votre nom et un nouveau nom de package.Cargo.toml .app.toml .cargo xtask build pour le compiler. Une entrée app.toml typique pour une petite tâche qui n'utilise aucun périphérique mappé par la mémoire ne lira
[ tasks . name_for_task_in_this_image ]
name = " my-task-target-name "
priority = 1
requires = { flash = 1024 , ram = 1024 }
start = true Un graphique peut être généré qui montre les relations des différentes tâches et de leurs priorités. Le fichier résultant est au format dot de Graphviz. La source Dot peut être incluse dans la source asciidoctor ou rendu à une variété de formats.
Pour créer et afficher un graphique SVG pour gimletlet sur Ubuntu, assurez-vous que le package graphviz est installé. Générez ensuite le graphique:
$ cargo xtask graph -o gimletlet.dot app/gimletlet/app.toml
$ dot -Tsvg gimletlet.dot > gimletlet.svg
$ xdg-open gimletlet.svgCommandes bash pour générer tous les graphiques:
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}" Si eog est la visionneuse par défaut, l'ouverture du premier SVG dans un répertoire permettra de faire du vélo via tous les graphiques disponibles en utilisant la même fenêtre.
Hubris est étroitement couplé à son débogueur, l'humilité, qui est utilisé pour les commandes ci-dessous soit implicitement (dans cargo xtask flash ) ou explicitement (dans cargo xtask humility ).
Si le binaire humility n'est pas disponible sur votre $PATH , la variable d'environnement HUBRIS_HUMILITY_PATH peut être utilisée pour fournir le chemin du binaire.
Une image au sein d'une archive Hubris peut être flassée directement sur une carte cible en exécutant cargo xtask flash et en spécifiant le fichier Toml approprié. Cela exécutera cargo xtask dist , puis passera les archives de construction résultantes à humility flash . humility invoquera OpenOCD ou PYOCD pour flasher l'image; L'invocation exacte dépend du conseil d'administration et est codée dans les archives de construction.
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 L'humilité est exécutée in situ en spécifiant une archive sur une carte directement connectée ou en postmortem en spécifiant un vidage. En tant que commodité pour le développement, l'humilité peut également être exécutée in situ en spécifiant le TOML approprié, par exemple sur une machine avec une carte de découverte STM32F4 directement attachée:
$ 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 comprend une sous-commande gdb qui se fixe à un système en cours d'exécution utilisant arm-none-eabi-gdb , exécutant éventuellement sa propre instance openocd en fonction des données de configuration dans l'archive de construction.
Pour plus de commodité, il y a aussi une façade cargo xtask gdb qui appelle humility avec les archives de construction appropriées:
$ 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) Notez que cargo xtask gdb (par défaut) exécutera également dist et flash , pour s'assurer que l'image sur la puce est à jour. L'option -n / --noflash saute ces étapes.
Le noyau de l'orgueil est testé avec une image de test dédiée qui comprend un coureur de test, un assistant et une suite de test. L'image de test émet ses résultats via ITM. Bien que ces résultats puissent être interprétés manuellement, humility test l'automatise. humility test lui-même est le plus facilement exécuté via cargo xtask test , qui exécute l'équivalent du cargo xtask dist , cargo xtask flash et cargo xtask humility test . L'invocation exacte dépend du conseil:
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 Remarque: cargo xtask humility test fonctionne OpenOCD pour se connecter à l'appareil. Vous devez quitter tout autre cas d'OpenOCD que vous avez connecté à l'appareil avant d'exécuter des tests.
Voir le humility test pour plus de détails sur les résultats des tests.
La sortie des tests est capturée par humility test ; sys_log!() Des appels à des tests peuvent être ajoutés puis capturés dans un vidage humility test . Pour capturer un vidage des tests qui se passent autrement, utilisez directement cargo xtask humility et passez le drapeau -d , par exemple:
$ 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 Si l'on doit à la fois exécuter GDB et la suite de tests, utilisez cargo xtask gdb avec le TOML de l'image de test et le fichier GDB approprié, puis placez les points d'arrêt au test d'intérêt.
Voir les Docs de démarrage des Gémeaux (Repo d'oxyde interne)
Pour le tableau de découverte STM32F3, SB10 doit être soudé fermé pour que l'ITM fonctionne! Ce pont de soudure est ouvert par défaut, ce qui laisse SWO déconnecté. Voir le STM32F3 Discovery User Manual (UM1570) pour le schéma et les détails.
Pour utiliser le LPCXPRESSO55S69, vous aurez besoin de PYOCD, version 0.27.0 ou ultérieure.
Le LPCXPRESSO55S69 est en quelque sorte un gâchis car le débogueur sur la puce construit, LPC-Link2, ne prend pas correctement en charge SWO / SWV
Si vous avez le stock LPC-Link2, il se rapportera de cette façon via pyocd list :
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------
0 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.361 JSAQCQIQ Il est également possible que vous ayez le firmware J-Link Segger - le firmware qui fera connaître sa présence odieuse en vous invitant à accepter des conditions de licence chaque fois que l'exécution pyocd list !
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------------------
0 Segger J-Link LPCXpresso V2 compiled Apr 4 2019 16:54:03 726424936Dans l'un ou l'autre des cas, vous devez - en tant qu'étape ponctuelle - installer un nouveau firmware sur le LPC-Link2. Le nouveau firmware est une construction du daplink (open source), que nous appelons affectueusement Ricklink après l'ingénieur qui a réussi à tout construire - pas un petit exploit!
Il y a deux fichiers dont vous aurez besoin, tous deux contenus dans le référentiel Hubris:
Vous aurez également besoin du programme LPCSCRYPT de NXP.
Voici les étapes pour installer Ricklink:
Installez le cavalier DFU. Cela peut être trouvé à côté de l'en-tête SWD sur le côté gauche de la planche; Il est étiqueté "DFU".
Exécutez scripts/boot_lpcscrypt à partir du logiciel LPCSCrypt installé:
$ /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 pour écraser le firmware existant $ /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)
$En supposant qu'il réussit, supprimez le cavalier DFU et déconnectez / reconnectez USB
Il devrait maintenant y avoir un périphérique de stockage de masse USB nommé 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 vers le lecteur USB $ sudo cp ~ /hubris/support/lpc4322_lpc55s69xpresso_if_rla_swo_hacks.bin /mnt
$# umount /mnt
# Vérifiez que vous êtes sur le nouveau firmware en exécutant pyocd list :
$ pyocd list
# Probe Unique ID
-------------------------------------------------------------------------------------
0 LPCXpresso55S69 [lpc55s69] 02360b000d96e4fc00000000000000000000000097969905 Notez que le Ricklink fonctionnant sur le LPCXPRESSO55S69 peut également être utilisé comme débogueur pour le LPC55S28 sur la carte de transporteur Gemini. Pour ce faire, suivez d'abord toutes les instructions ci-dessus pour amener Ricklink sur votre LPCXPRESSO55S69. Alors:
À l'aide d'un fer à souder, soudez un en-tête à deux broches sur J5. J5 peut être trouvé à gauche de P1 et en dessous du cavalier "débogueur" (J3).
Mettez un cavalier sur la nouvelle en-tête
Déplacez le cavalier "Debugger" (J3) vers "ext".
Utilisez un câble SWD (câble de tangage à 10 broches 2x5 1,27 mm) pour connecter le SWD sur le LPCXPRESSO55S69 au SWD sous la carte de transporteur sur Gémeaux (J202)
(Pour permettre à votre Ricklink de déboguer à nouveau son LPC55S69 local, retirez le cavalier sur J5 et déplacez J3 vers "LOC".)
Si plusieurs sondes sont attachées, les outils peuvent avoir du mal à trouver le bon au bon moment. En particulier, OpenOCD choisira le premier qu'il trouve; Pour forcer OpenOCD à choisir une sonde particulière , vous pouvez vérifier le numéro de série de la sonde (par exemple, à partir de humility probe ), puis spécifier ce numéro de série dans l' openocd.cfg correspondant en ajoutant, par exemple:
interface hla
hla_serial 271828182845904523536028
(Où 271828182845904523536028 est le numéro de série de la sonde.)
Il est courant que le débogage des dongles et des cartes de développement avec du matériel de débogage intégré comme la série Nucleo soient livrés avec un micrologiciel plus ancien.
Vous ne pourrez pas utiliser l'humilté avec le firmware ST-Link obsolète. L'humilité vous dira que c'est le cas, par exemple lors de la tentative d'utilisation 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
Suivez ce lien "ST-Link Firmware Medgrade" pour trouver des logiciels et des instructions nécessaires pour installer le firmware actuel.
