hubris
sidecar release
Hubris es un entorno operativo de microcontroladores diseñado para sistemas profundamente incrustados con requisitos de confiabilidad. Su diseño se propuso inicialmente en RFD41, pero ha evolucionado considerablemente desde entonces.
Developer documentation is in Asciidoc in the doc/ directory. Se renderiza a través de páginas Github, y está disponible en https://oxidecomputer.github.io/hubris.
El repositorio se presenta de la siguiente manera.
app/ es donde viven las cajas binarias de nivel superior para aplicaciones, por ejemplo, app/gimlet contiene la caja de firmware para Gimlet. En términos generales, si quieres construir una imagen para algo, mira aquí.
build/ Contiene el sistema de compilación y las cajas de soporte.
chip/ contiene definiciones periféricas y archivos de soporte de depuración para microcontroladores individuales.
doc/ Contiene documentación del desarrollador.
drv/ Contiene controladores, una combinación de cajas libres de controlador simples y cajas de contenedores de servidor totalmente de pleno derecho. La convención actual es que drv/SYSTEM-DEVICE es el controlador para DEVICE en SYSTEM (donde SYSTEM suele ser un nombre SOC), mientras que drv/SYSTEM-DEVICE-server es la caja de contenedores del servidor.
idl/ Contiene definiciones de interfaz escritas en Idol
lib/ contiene bibliotecas de servicios públicos variados que hemos escrito. Si necesita hacer una caja reutilizable que no se ajuste a uno de los otros directorios, probablemente pertenezca aquí.
stage0/ es el cargador de arranque/ hipovisor, principalmente para LPC55.
support/ contiene algunos archivos de soporte de interfaz y programación, como certificados falsos e imágenes de firmware del programador.
sys/ Contiene los bits de "Sistema" de Hubris, a saber, el núcleo ( sys/kern ), la caja compartida que define el ABI ( sys/abi ) y la biblioteca de usuario utilizada por tareas ( sys/userlib ).
task/ Contiene tareas reutilizables que no son conductores. La distinción entre cosas que viven en task vs en drv/something-server es confusa. Usa tu juicio.
test/ contiene el marco de prueba y las cajas binarias para construirlo para varios tableros.
website/ Contiene el código fuente del sitio web de Hubris
Actualmente admitimos Linux y Windows como plataformas de primer nivel. Los empleados de óxido también usan MacOS a diario, pero no se prueba en CI. La construcción probablemente también funciona en Illumos; Si a alguien le gustaría dar un paso adelante para mantener el apoyo y una construcción continua para Illumos o MacOS, nos encantaría la ayuda.
Para enviar cambios para su revisión, empújalos a una sucursal en una bifurcación y envíe una solicitud de extracción para fusionar esa rama en master . Para más detalles, ver CONTRIBUTING.md . MD.
Necesitarás:
Una instalación de cadena de herramientas basada en rustup . rustup se encargará de instalar automáticamente nuestra versión de cadena de herramientas cubierta y los objetivos de compilación cruzada, cuando intente construir por primera vez.
openocd (idealmente 0.11) o (si usa el pyocd LPC55) (0.27 o posterior). Tenga en cuenta que la liberación 0.10 de OpenOCD es anterior al stlink v3. Las personas están utilizando varias compilaciones posteriores al 0.10, antes del 0.11 proporcionadas por los administradores de paquetes de sistemas, con cierto éxito, pero si su sistema aún no está empaquetando 0.11, molestalos. Si va a usar HomeBrew en MacOS para instalar OpenOCD, debe usar brew install --head openocd para construir la punta de la rama principal en lugar de usar la última versión binaria. Si necesita construir desde la fuente, puede encontrar OpenOCD V0.11.0 aquí. Al ejecutar ./configure , asegúrese de ver que el ST-Link Programmer está configurado (que debería ser el valor predeterminado).
LibUSB, típicamente encontrado en el Administrador de paquetes de su sistema como libusb-1.0.0 o similar.
libfdti1, encontrado como libftdi1-dev o similar.
Si va a ejecutar GDB, debe instalar arm-none-eabi-gdb . Esto es típicamente del Administrador de paquetes de su sistema con un nombre de paquete como arm-none-eabi-gdb o gdb-multiarch . Los usuarios de MACOS pueden ejecutar brew install --cask gcc-arm-embedded para instalar los binarios oficiales del brazo.
El depurador de la arrogancia, humildad. Tenga en cuenta que cargo install interactúa extrañamente con el archivo rust-toolchain.toml presente en la raíz de este repositorio; Si ejecuta el siguiente comando textualmente para instalar Humility, hágalo desde un directorio diferente:
cargo install --git https://github.com/oxidecomputer/humility.git --locked humilitycargo-readme como dependencia: cargo install cargo-readmeHay tres formas alternativas de instalar OpenOCD:
Vea aquí para obtener la fuente de openocd o obtener binarios no oficiales.
Alternativamente, puede instalar con chocolate:
> choco install openocd Por último, puede instalar openocd con SCOOP:
> scoop bucket add extras
> scoop install openocd Nota: openocd instalado a través de scoop ha demostrado ser problemático para algunos usuarios. Si experimenta problemas, intente instalar a través de choco o desde la fuente (ver arriba).
Para usar el programador ST-Link, probablemente necesite instalar este controlador.
No es necesario construir y ejecutar arrogancia, pero si desea comunicarse a través de un enlace en serie (y eso no es compatible con su terminal), querrá usar masilla; Esta guía hace un buen trabajo al explicar cómo.
No utilizamos cargo build o cargo run directamente porque son demasiado inflexibles para nuestros propósitos. Tenemos una compleja construcción de arquitectura múltiple, que está un poco más allá de ellos.
En su lugar, el repositorio incluye una extensión de carga llamada xtask que espacia a nuestros comandos de compilación personalizados.
cargo xtask dist TOMLFILE crea una imagen de distribución para la aplicación descrita por el archivo Toml.
cargo xtask dist app/demo-stm32f4-discovery/app.toml -STM32F4-Descubrimientocargo xtask dist app/demo-stm32f4-discovery/app-f3.toml -STM32F3 Descubrimientocargo 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 Porque una compilación de imagen completa puede tomar 10 segundos o más, dependiendo de lo que haya cambiado, cuando está iterando en una tarea o núcleo, probablemente querrá construirla por separado. Para esto es para lo que es cargo xtask build .
Por ejemplo, para construir task-ping , ya que se construiría en una de las imágenes, pero sin construir el resto de la demostración, ejecute:
$ cargo xtask build app/gimletlet/app.toml ping clippy El subcomando cargo xtask clippy se puede usar para ejecutar clippy contra una o más tareas en el contexto de una imagen particular:
$ cargo xtask clippy app/gimletlet/app.toml ping pong rust-analyzer El sistema de construcción de la arrogancia no funcionará con rust-analyzer .
Sin embargo, cargo xtask lsp está aquí para ayudar: toma como argumento un archivo de óxido y devuelve la configuración codificada por JSON sobre cómo configurar rust-analyzer .
Para usar estos datos, se requiere alguna configuración del editor.
(Aún no hemos hecho complementos, pero ciertamente sería posible)
Usando neovim y rust-tools , aquí hay una configuración de ejemplo:
-- 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 Cuando se crea una nueva configuración de LSP ( on_new_config ), ejecutamos cargo xtask lsp en el archivo de destino. La configuración JSON incluye un hash de la configuración; Utilizamos ese hash para modificar el nombre del cliente de rust_analyzer a rust_analyzer_$HASH . Esto evita que Neovim intente reutilizar a un cliente existente, que normalmente se dedican mediante el nombre del cliente y el directorio raíz del espacio de trabajo; En Hubris, queremos que varios clientes coexistan con la misma raíz del espacio de trabajo, por lo que necesitan diferentes nombres. Luego, guardamos el resto de la configuración en una variable local ( cache ) y registramos la existencia de este cliente en clients .
Al unirnos al LSP, intentamos sacar la configuración del cache . Si uno existe, entonces sabemos que estamos tratando con un amortiguador de arrogancia; Copie sobre partes relevantes de la configuración.
Tenga en cuenta que esto no compila xtask para usted; Se supone que ya existe en target/debug/xtask . Esto debería ser cierto si está usando arrogancia regularmente y ahorra cantidades significativas de tiempo al abrir un nuevo archivo.
Para crear su propia tarea, el método más fácil es:
task/template a un nuevo nombre.Cargo.toml con su nombre y un nuevo nombre de paquete.Cargo.toml .app.toml .cargo xtask build para compilarlo. Se leería una entrada típica app.toml
[ tasks . name_for_task_in_this_image ]
name = " my-task-target-name "
priority = 1
requires = { flash = 1024 , ram = 1024 }
start = true Se puede generar un gráfico que muestre las relaciones de las diversas tareas y sus prioridades. El archivo resultante está en el formato dot de GraphViz. La fuente Dot se puede incluir en la fuente Asciidoctor o en una variedad de formatos.
Para crear y ver un gráfico SVG para gimletlet en Ubuntu, asegúrese de que el paquete graphviz esté instalado. Luego genere el gráfico:
$ cargo xtask graph -o gimletlet.dot app/gimletlet/app.toml
$ dot -Tsvg gimletlet.dot > gimletlet.svg
$ xdg-open gimletlet.svgComandos bash para generar todos los gráficos:
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 es el visor predeterminado, abrir el primer SVG en un directorio permitirá el ciclismo a través de todos los gráficos disponibles utilizando la misma ventana.
La Hubris está bien acoplada a su depurador, la humildad, que se utiliza para los comandos a continuación, ya sea implícitamente (en cargo xtask flash ) o explícitamente (en cargo xtask humility ).
Si el binario humility no está disponible en su $PATH , la variable de entorno HUBRIS_HUMILITY_PATH puede usarse para proporcionar la ruta al binario.
Una imagen dentro de un archivo de Hubris se puede flashear directamente en una tabla de destino ejecutando cargo xtask flash y especificando el archivo Toml apropiado. Esto ejecutará cargo xtask dist y luego pasará el archivo de compilación resultante al humility flash . humility invocará OpenOcd o Pyocd para flashear la imagen; La invocación exacta depende de la Junta y está codificada en el archivo de compilación.
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 La humildad se ejecuta in situ especificando un archivo en una placa conectada directamente o postmortem especificando un volcado. Como conveniencia para el desarrollo, la humildad también se puede ejecutar in situ especificando el TOML apropiado, por ejemplo, en una máquina con una placa de descubrimiento STM32F4 directamente adjunta:
$ 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 incluye un subcomando gdb que se adhiere a un sistema en ejecución utilizando arm-none-eabi-gdb , que opcionalmente ejecuta su propia instancia openocd en función de los datos de configuración en el archivo de compilación.
Por conveniencia, también hay una fachada cargo xtask gdb que llama humility con el archivo de compilación apropiado:
$ 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) Tenga en cuenta que cargo xtask gdb (por defecto) también ejecutará dist y flash , para asegurarse de que la imagen en el chip esté actualizada. La opción -n / --noflash omite estos pasos.
El núcleo de la arrogancia se prueba con una imagen de prueba dedicada que incluye un corredor de prueba, asistente y suite de prueba. La imagen de prueba emite sus resultados a través de ITM. Si bien estos resultados se pueden interpretar manualmente, humility test automatiza esto. humility test en sí se ejecuta más fácilmente a través de cargo xtask test , que ejecuta el equivalente de cargo xtask dist , cargo xtask flash y cargo xtask humility test . La invocación exacta depende de la Junta:
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 Nota: cargo xtask humility test se ejecuta OpenOCD para conectarse al dispositivo. Debe salir de cualquier otra instancia de OpenOCD que haya conectado al dispositivo antes de ejecutar pruebas.
Consulte la prueba de documentación para humility test para obtener detalles sobre los resultados de las pruebas.
La salida de las pruebas se captura mediante humility test ; sys_log!() Las llamadas a las pruebas se pueden agregar y luego capturarse en un volcado humility test . To capture a dump from tests that are otherwise passing, use cargo xtask humility directly and pass the -d flag, eg:
$ 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 uno necesita ejecutar GDB y el suite de prueba, use cargo xtask gdb con el TOML de la imagen de prueba y el archivo GDB apropiado, y luego coloque los puntos de interrupción en prueba de interés.
Vea los documentos de Gemini Traup que se inician (repositorio de óxido interno)
Para el tablero de descubrimiento STM32F3, SB10 debe ser soldado cerrado para que ITM funcione. Este puente de soldadura predetermina ser abierto, lo que deja SWO desconectado. Consulte el Manual del usuario de Discovery STM32F3 (UM1570) para ver esquemas y detalles.
Para usar el LPCXPresso55S69, necesitará Pyocd, versión 0.27.0 o posterior.
El LPCXPresso55S69 es un desastre porque el depurador construido en chip, LPC-Link2, no admite correctamente SWO/SWV
Si tiene el stock LPC-Link2, se informará de esta manera a través de pyocd list :
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------
0 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.361 JSAQCQIQ ¡También es posible que tenga el firmware Segger J-Link, firmware que hará que su presencia odiosa se dé cuenta al solicitar que acepte términos de licencia cuando ejecute pyocd list !
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------------------
0 Segger J-Link LPCXpresso V2 compiled Apr 4 2019 16:54:03 726424936En cualquiera de estos casos, debe, como un paso único, instalar un nuevo firmware en el LPC-Link2. El nuevo firmware es una construcción del Daplink (de código abierto), que llamamos cariñosamente a Ricklink después del ingeniero que logró construirlo todo, ¡no es una hazaña pequeña!
Hay dos archivos que necesitará, ambos contenidos en el repositorio de Hubris:
Además, necesitará el programa LPCSCRYPT de NXP.
Estos son los pasos para instalar Ricklink:
Instale el Jumper DFU. Esto se puede encontrar al lado del encabezado SWD en el lado izquierdo del tablero; Está etiquetado como "DFU".
Ejecutar scripts/boot_lpcscrypt desde el software LPCSCRYPT instalado:
$ /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 para sobrescribir el firmware existente $ /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)
$Suponiendo que sea exitoso, elimine el jersey de DFU y desconecte/vuelva a conectar USB
Ahora debería haber un dispositivo de almacenamiento masivo USB llamado 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 a la unidad USB $ sudo cp ~ /hubris/support/lpc4322_lpc55s69xpresso_if_rla_swo_hacks.bin /mnt
$# umount /mnt
# Verifique que esté en el nuevo firmware ejecutando pyocd list :
$ pyocd list
# Probe Unique ID
-------------------------------------------------------------------------------------
0 LPCXpresso55S69 [lpc55s69] 02360b000d96e4fc00000000000000000000000097969905 Tenga en cuenta que el Ricklink que se ejecuta en el LPCXPresso55S69 también se puede utilizar como depurador para el LPC55S28 en el tablero de operadores de Gemini. Para hacer esto, primero, siga todas las instrucciones anteriores para llevar a Ricklink a su LPCXPresso55S69. Entonces:
Usando un soldador, soldadura un encabezado de dos pines en J5. J5 se puede encontrar a la izquierda de P1 y debajo del saltador "depurador" (J3).
Pon un puente en el nuevo encabezado
Mueva el jersey "debugger" (J3) a "ext".
Use un cable SWD (cable de lanzamiento de 10 pines 2x5 1.27 mm) para conectar el SWD en el LPCXPresso55S69 al SWD debajo del tablero de portadores de Gemini (J202)
(Para permitir que su Ricklink depugte una vez más su LPC55S69 local, retire el puente en J5 y mueva J3 a "loc").
Si se adjuntan múltiples sondas, las herramientas pueden tener dificultades para encontrar la correcta en el momento correcto. En particular, OpenOcd elegirá el primero que encuentra; Para obligar a OpenOcd a elegir una sonda particular , puede determinar el número de serie de la sonda (por ejemplo, de humility probe ) y luego especificar ese número de serie en el correspondiente openocd.cfg agregando, por ejemplo:
interface hla
hla_serial 271828182845904523536028
(Donde 271828182845904523536028 es el número de serie de la sonda).
Es común que los dongles de depuración y los tableros de desarrollo con hardware de depuración integrado como la serie Nuceo, se entreguen con firmware más antiguo.
No podrá usar HumiLty con firmware de ST-Link obsoleto. La humildad le dirá que este es el caso, por ejemplo, cuando se intenta usar 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
Siga este enlace "actualización de firmware ST-Link" para encontrar software e instrucciones necesarias para instalar el firmware actual.
