hubris
sidecar release
Hubris é um ambiente operacional de microcontrolador projetado para sistemas profundamente embebidos com requisitos de confiabilidade. Seu design foi proposto inicialmente no RFD41, mas evoluiu consideravelmente desde então.
A documentação do desenvolvedor está no ASCIIDOC no doc/ Diretório. Ele é renderizado pelas páginas do Github e está disponível em https://oxidecomputer.github.io/hubris.
O repositório é estabelecido da seguinte maneira.
app/ é onde as caixas binárias de nível superior para aplicativos ao vivo, por exemplo, app/gimlet contém a caixa de firmware para gimlet. De um modo geral, se você deseja criar uma imagem para alguma coisa, olhe aqui.
build/ contém o sistema de construção e caixas de suporte.
chip/ contém definições periféricas e arquivos de suporte de depuração para microcontroladores individuais.
doc/ contém documentação do desenvolvedor.
drv/ contém drivers, uma mistura de caixas de lib de driver simples e caixas de bin de servidor de pleno direito. A Convenção atual é que drv/SYSTEM-DEVICE é o driver para DEVICE no SYSTEM (onde SYSTEM geralmente é um nome de SOC), enquanto drv/SYSTEM-DEVICE-server é a caixa do servidor.
idl/ contém definições de interface escritas no ídolo
lib/ contém bibliotecas de serviços públicos variados que escrevemos. Se você precisar fazer uma caixa reutilizável que não se encaixe em um dos outros diretórios, provavelmente pertence aqui.
stage0/ é o carregador de inicialização/ hipovisor, principalmente para LPC55.
support/ contém alguns arquivos de suporte de interface e programação, como certificados falsos e imagens de firmware do programador.
sys/ contém os bits "System" da arrogância, a saber, o kernel ( sys/kern ), a caixa compartilhada que define o ABI ( sys/abi ) e a biblioteca de usuários usada por tarefas ( sys/userlib ).
task/ contém tarefas reutilizáveis que não são drivers. A distinção entre coisas que vivem na task vs no drv/something-server é confusa. Use seu julgamento.
test/ contém a estrutura de teste e caixas binárias para construí -lo para várias placas.
website/ contém o código -fonte do site da Hubris
Atualmente, oferecemos suporte ao Linux e Windows como plataformas de primeira linha. O MacOS também é usado diariamente por funcionários de óxido, mas não é testado no IC. A construção provavelmente também funciona em Illumos; Se alguém gostaria de intensificar para manter o apoio e uma construção contínua para ilumos ou macos, adoraríamos a ajuda.
Para enviar alterações para revisão, empurre -as para uma filial em um garfo e envie uma solicitação de tração para mesclar essa filial para master . Para detalhes, consulte CONTRIBUTING.md .
Você precisará:
Uma instalação de cadeia de ferramentas à base de rustup . rustup cuidará automaticamente de instalação de nossa versão de cadeia de ferramentas fixada e os alvos de compilação cruzada, quando você tenta construir pela primeira vez.
openocd (idealmente 0,11) ou (se estiver usando o pyocd LPC55) (0,27 ou posterior). Observe que a versão 0.10 do OpenocD antecede o Stlink V3. As pessoas estão usando várias compilações pós-0.10, pré-0.11 fornecidas pelos gerentes de pacotes do sistema, com algum sucesso, mas se o seu sistema ainda não estiver embalando 0.11, incomodá-las. Se você vai usar o homebrew no macOS para instalar o Openocd, precisará usar brew install --head openocd para construir a ponta da filial principal, em vez de usar a versão mais recente binária. Se você precisar construir a partir da fonte, pode encontrar o Openocd v0.11.0 aqui. Ao executar ./configure , verifique se o ST-Link Programmer está definido ativado (que deve ser o padrão).
Libusb, normalmente encontrado no gerenciador de pacotes do seu sistema como libusb-1.0.0 ou similar.
libfdti1, encontrado como libftdi1-dev ou similar.
Se você estiver executando o GDB, instale arm-none-eabi-gdb . Normalmente, isso é do gerenciador de pacotes do seu sistema com um nome de pacote como arm-none-eabi-gdb ou gdb-multiarch . Os usuários do MacOS podem executar brew install --cask gcc-arm-embedded para instalar os binários oficiais do braço.
O depurador da arrogância, humildade. Observe que cargo install interage estranhamente com o arquivo rust-toolchain.toml presente na raiz deste repositório; Se você executar o seguinte comando literalmente para instalar a humildade, faça -o de um diretório diferente:
cargo install --git https://github.com/oxidecomputer/humility.git --locked humilitycargo-readme como uma dependência: cargo install cargo-readmeExistem três maneiras alternativas de instalar o Openocd:
Veja aqui para obter a fonte do openocd ou obter binários não oficiais.
Como alternativa, você pode instalar com chocolate:
> choco install openocd Por fim, você pode instalar openocd com SCOOP:
> scoop bucket add extras
> scoop install openocd NOTA: openocd instalado via scoop se mostrou problemático para alguns usuários. Se você tiver problemas, tente instalar via choco ou da fonte (veja acima).
Para usar o programador ST-Link, você provavelmente precisará instalar esse driver.
Não é necessário construir e executar a arrogância, mas se você deseja se comunicar com um link serial (e isso não é suportado pelo seu terminal), você deseja usar a massa; Este guia faz um bom trabalho ao explicar como.
Não usamos cargo build ou cargo run diretamente porque eles são muito inflexíveis para nossos propósitos. Temos uma compilação complexa de multi-arquitetura, que está um pouco além deles.
Em vez disso, o repositório inclui uma extensão de carga chamada xtask , que nomeia nossos comandos de construção personalizados.
cargo xtask dist TOMLFILE cria uma imagem de distribuição para o aplicativo descrito pelo arquivo 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 - LPCXPRESS55S69cargo 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 Como uma construção de imagem completa pode levar 10 segundos ou mais, dependendo do que você mudou, quando você está iterando em uma tarefa ou kernel, você provavelmente desejará construí -lo separadamente. É para isso que cargo xtask build .
Por exemplo, para construir task-ping , pois seria construído em uma das imagens, mas sem construir o restante da demonstração, execute:
$ cargo xtask build app/gimletlet/app.toml ping clippy O Subcomando cargo xtask clippy pode ser usado para executar clippy contra uma ou mais tarefas no contexto de uma imagem específica:
$ cargo xtask clippy app/gimletlet/app.toml ping pong rust-analyzer O sistema de construção de arrogância não funcionará com rust-analyzer pronta para uso.
No entanto, cargo xtask lsp está aqui para ajudar: é preciso como argumento um arquivo de ferrugem e retorna a configuração codificada por JSON para como configurar rust-analyzer .
Para usar esses dados, é necessária alguma configuração do editor!
(Ainda não fizemos plugins, mas certamente seria possível)
Usando rust-tools , aqui está uma configuração de exemplo:
-- 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 Quando uma nova configuração LSP é criada ( on_new_config ), executamos cargo xtask lsp no arquivo de destino. A configuração JSON inclui um hash da configuração; Usamos esse hash para modificar o nome do cliente de rust_analyzer para rust_analyzer_$HASH . Isso impede que a Neovim tente reutilizar um cliente existente, que normalmente é desduplicado pelo nome do cliente e diretório raiz da área de trabalho; Na arrogância, queremos que vários clientes coexistam com a mesma raiz da área de trabalho, para que eles precisem de nomes diferentes. Em seguida, escondemos o restante da configuração em uma variável local ( cache ) e registramos a existência desse cliente nos clients .
Ao conectar ao LSP, tentamos retirar a configuração do cache . Se alguém existir, sabemos que estamos lidando com um buffer de arrogância; Copie as partes relevantes da configuração.
Observe que isso não compila xtask para você; Ele assume que já existe no target/debug/xtask . Isso deve ser verdade se você estiver usando a arrogância regularmente e economiza quantidades significativas de tempo ao abrir um novo arquivo.
Para criar sua própria tarefa, o método mais fácil é:
task/template para um novo nome.Cargo.toml com seu nome e um novo nome de pacote.Cargo.toml .app.toml .cargo xtask build para compilá -lo. Uma entrada típica app.toml para uma pequena tarefa que não usa periféricos mapeados de memória que lia
[ tasks . name_for_task_in_this_image ]
name = " my-task-target-name "
priority = 1
requires = { flash = 1024 , ram = 1024 }
start = true Pode -se gerar um gráfico que mostre as relações das várias tarefas e suas prioridades. O arquivo resultante está no formato dot do GraphViz. A fonte Dot pode ser incluída na fonte de asidoctor ou renderizada a uma variedade de formatos.
Para criar e visualizar um gráfico SVG para gimletlet no Ubuntu, verifique se o pacote graphviz está instalado. Em seguida, gerar o gráfico:
$ cargo xtask graph -o gimletlet.dot app/gimletlet/app.toml
$ dot -Tsvg gimletlet.dot > gimletlet.svg
$ xdg-open gimletlet.svgComandos bash para gerar todos os 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}" Se eog for o visualizador padrão, a abertura do primeiro SVG em um diretório permitirá o ciclismo por todos os gráficos disponíveis usando a mesma janela.
A arrogância é fortemente acoplada ao seu depurador, a humildade, que é usada para os comandos abaixo, implicitamente (no cargo xtask flash ) ou explicitamente (na cargo xtask humility ).
Se o binário humility não estiver disponível no seu $PATH , a variável de ambiente HUBRIS_HUMILITY_PATH pode ser usada para fornecer o caminho para o binário.
Uma imagem dentro de um arquivo de Hubris pode ser exibida diretamente em uma placa de destino executando cargo xtask flash e especificando o arquivo TOML apropriado. Isso executará cargo xtask dist e depois passará o arquivo de construção resultante para humility flash . humility invocará o Openocd ou o PYOCD para exibir a imagem; A invocação exata depende da placa e é codificada no arquivo de construção.
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 A humildade é executada in situ especificando um arquivo em uma placa diretamente conectada ou post -mortem especificando um despejo. Como uma conveniência para o desenvolvimento, a humildade também pode ser executada in situ especificando o toml apropriado, por exemplo, uma máquina com uma placa de descoberta STM32F4 diretamente anexada:
$ 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 inclui um subcomando gdb que se conecta a um sistema em execução usando arm-none-eabi-gdb , executando opcionalmente sua própria instância openocd com base em dados de configuração no arquivo de construção.
Por conveniência, também há uma fachada cargo xtask gdb que chama humility com o arquivo de construção apropriado:
$ 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) Observe que cargo xtask gdb (por padrão) também será dist e flash , para garantir que a imagem no chip esteja atualizada. A opção -n / --noflash pula estas etapas.
O kernel da arrogância é testado com uma imagem de teste dedicada que inclui um corredor de teste, assistente e conjunto de testes. A imagem de teste emite seus resultados via ITM. Embora esses resultados possam ser interpretados manualmente, humility test automatiza isso. humility test em si é executado mais facilmente via cargo xtask test , que executa o equivalente a cargo xtask dist , cargo xtask flash e cargo xtask humility test . A invocação exata depende do quadro:
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 é executado no Openocd para se conectar ao dispositivo. Você deve sair de outras instâncias do Openocd que você conectou ao dispositivo antes de executar os testes.
Consulte a documentação para humility test para obter detalhes sobre os resultados dos testes.
A saída dos testes é capturada pelo humility test ; sys_log!() As chamadas para testes podem ser adicionadas e depois capturadas em um despejo humility test . Para capturar um despejo de testes que estão passando, use cargo xtask humility diretamente e passe a bandeira -d , por exemplo:
$ 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 Se for necessário executar o GDB e o conjunto de testes, use cargo xtask gdb com o TOML da imagem de teste e o arquivo GDB apropriado e coloque pontos de interrupção no teste de interesse.
Veja o Gêmeos Bringup para iniciar os documentos (repo interno de óxido)
Para o STM32F3 Discovery Board, o SB10 deve ser soldado fechado para que o ITM funcione! Essa ponte de solda padrão está aberta, o que deixa o SWO desconectado. Consulte o Manual do Usuário do STM32F3 Discovery (UM1570) para obter detalhes esquemáticos e detalhes.
Para usar o LPCXRESO55S69, você precisará de Pyocd, versão 0.27.0 ou posterior.
O LPCXRESO55S69 é um pouco de bagunça porque o depurador embutido no chip, LPC-Link2, não suporta corretamente o SWO/SWV
Se você tiver o Stock LPC-Link2, ele se reportará dessa maneira via pyocd list :
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------
0 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.361 JSAQCQIQ Também é possível que você tenha o firmware do Segger J-Link-firmware que tornará sua presença odiosa conhecida ao solicitar que você aceite termos de licença sempre que executar pyocd list !
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------------------
0 Segger J-Link LPCXpresso V2 compiled Apr 4 2019 16:54:03 726424936Em qualquer um desses casos, você deve-como uma etapa única-instalar um novo firmware no LPC-Link2. O novo firmware é uma construção do Daplink (de código aberto), que chamamos de Ricklink depois do engenheiro que conseguiu construir tudo - não é pequeno feito!
Existem dois arquivos que você precisará, ambos contidos no repositório da arrogância:
Além disso, você precisará do programa LPCScrypt da NXP.
Aqui estão as etapas para instalar o Ricklink:
Instale o jumper DFU. Isso pode ser encontrado ao lado do cabeçalho do SWD no lado esquerdo da placa; É rotulado como "DFU".
Execute scripts/boot_lpcscrypt no 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 substituir o 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)
$Supondo que seja bem -sucedido, remova o jumper DFU e desconecte/reconecte USB
Agora deve haver um dispositivo de armazenamento em massa USB chamado de 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 para a unidade USB $ sudo cp ~ /hubris/support/lpc4322_lpc55s69xpresso_if_rla_swo_hacks.bin /mnt
$# umount /mnt
# Verifique se você está no novo firmware executando pyocd list :
$ pyocd list
# Probe Unique ID
-------------------------------------------------------------------------------------
0 LPCXpresso55S69 [lpc55s69] 02360b000d96e4fc00000000000000000000000097969905 Observe que o Ricklink em execução no LPCXPRESS55S69 também pode ser usado como o depurador do LPC55S28 na placa transportadora de Gêmeos. Para fazer isso, primeiro, siga todas as instruções acima para obter o Ricklink no seu LPCXPRESS55S69. Então:
Usando um ferro de solda, solda um cabeçalho de dois pinos no J5. J5 pode ser encontrado à esquerda de P1 e abaixo do jumper "depurador" (J3).
Coloque um jumper no novo cabeçalho
Mova o jumper "depurador" (J3) para "ext".
Use um cabo SWD (cabo de inclinação de 10 pinos de 2x5 1,27 mm) para conectar o SWD no LPCXPRESS55S69 ao SWD embaixo da placa transportadora em Gemini (J202)
(Para permitir que seu Ricklink depure mais uma vez o LPC55S69 local, remova o saltador no J5 e mova J3 para "LOC".)
Se várias sondas forem anexadas, as ferramentas poderão ter dificuldades para encontrar a correta na hora certa. Em particular, o Openocd escolherá o primeiro que encontra; Para forçar o Openocd a escolher uma sonda específica , você pode verificar o número de série da sonda (por exemplo, da humility probe ) e depois especificar esse número de série no openocd.cfg correspondente, por exemplo:
interface hla
hla_serial 271828182845904523536028
(Onde 271828182845904523536028 é o número de série da sonda.)
É comum que os dongles de depuração e os quadros de desenvolvimento com hardware de depuração incorporados como a série Nucleo sejam entregues com firmware mais antigo.
Você não poderá usar humilhado com firmware ST-Link desatualizado. A humildade dirá que esse é o caso, por exemplo, ao tentar 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 link "Atualização de firmware do ST-Link" para encontrar software e instruções necessárias para instalar o firmware atual.
