The humility lsusb command claims that probe IDs are output in the format VID:PID:SERIAL, which is the format that a Humility environment JSON file or humility -p expects probes to be listed. However, the actual output appears to be backwards. For example, when I run humility lsusb with two ST-Link probes connected to my system, I get this output:
eliza@theseus $ humility lsusb
humility: USB device scan, 2 successful and 32 failed
humility: --- successfully opened devices ---
humility: format: VID:PID:SERIAL, then manufacturer name, then product name
humility: 374e:0483:0030003C3431511237393330 STMicroelectronics STLINK-V3
humility: 3754:0483:000B00154D46501520383832 STMicroelectronics STLINK-V3
humility: --- failures ---
humility: could not access 32 devices:
...
On the other hand, the Linux lsusb(8) utility disagrees with humility lsusb, if I list devices by VID 0483, I see both ST-Links:
eliza@theseus $ lsusb -d 0483:
Bus 005 Device 034: ID 0483:3754 STMicroelectronics STLINK-V3
Bus 005 Device 044: ID 0483:374e STMicroelectronics STLINK-V3
which seems correct to me --- I would expect both ST-Links to have the same VID but different PIDs, rather than differing VIDs.
I'll also note that if the humility lsusb output is copied directly to the --probe command-line option, Humility doesn't like it, but if I swap the order of the two IDs, it works:
eliza@theseus $ humility --probe 374e:0483:0030003C3431511237393330 -a ~/Code/oxide/hubris/target/gimletlet/dist/default/build-gimletlet-image-default.zip tasks
humility tasks failed: Probe could not be created
Caused by:
Probe was not found.
eliza@theseus $ humility --probe 0483:374e:0030003C3431511237393330 -a ~/Code/oxide/hubris/target/gimletlet/dist/default/build-gimletlet-image-default.zip tasks
humility: attached to 0483:374e:0030003C3431511237393330 via ST-Link V3
system time = 19248
ID TASK GEN PRI STATE
0 jefe 0 0 recv, notif: fault timer(T+52)
1 sys 0 1 recv, notif: exti-wildcard-irq(irq6/irq7/irq8/irq9/irq10/irq23/irq40)
2 i2c_driver 0 2 recv
3 user_leds 0 5 recv, notif: timer
4 pong 0 8 recv, notif: timer(T+252)
5 uartecho 0 3 notif: usart-irq(irq38)
6 hiffy 0 7 notif: bit31(T+94)
7 validate 0 3 recv
8 idle 0 9 RUNNING
9 rng_driver 0 6 recv
10 update_server 0 3 recv
11 caboose_reader 0 2 recv
12 packrat 0 3 recv
13 control_plane_agent 0 7 wait: send to net/gen35
14 sensor 0 5 recv
15 dump_agent 0 6 recv, notif: socket
16 gimlet_seq 0 2 recv
17 host_sp_comms 0 8 wait: send to hf/gen0
18 hf 0 6 notif: bit31(T+789)
19 hash_driver 0 2 recv
20 net 163 3 notif: bit31(T+39)
21 udprpc 0 6 wait: send to net/gen35
22 udpecho 0 4 wait: send to net/gen35
23 udpbroadcast 0 6 wait: send to net/gen35
24 sprot 0 5 recv
The
humility lsusbcommand claims that probe IDs are output in the formatVID:PID:SERIAL, which is the format that a Humility environment JSON file orhumility -pexpects probes to be listed. However, the actual output appears to be backwards. For example, when I runhumility lsusbwith two ST-Link probes connected to my system, I get this output:On the other hand, the Linux
lsusb(8)utility disagrees withhumility lsusb, if I list devices by VID 0483, I see both ST-Links:which seems correct to me --- I would expect both ST-Links to have the same VID but different PIDs, rather than differing VIDs.
I'll also note that if the
humility lsusboutput is copied directly to the--probecommand-line option, Humility doesn't like it, but if I swap the order of the two IDs, it works: