Found while reviewing
feat/v06-batch at 13891f1. Three small defects in the same area; grouped because they are one fix pass.
1. missing_tool_message asserts a conclusion it did not check
python/tan/core/setools.py:136-146 emits "this does not look like an Alif Security Toolkit install" identically for:
- a directory that does not exist at all;
SETOOLS_DIR pointed at the app-gen-toc binary instead of its parent;
- a genuine Windows SETOOLS install.
find_app_gen_toc (:111-119) tests exactly one extension-less filename and never app-gen-toc.exe. The Linux-only bundle stance is deliberate and matches doctor_cmd's SETOOLS_BUNDLE = "app-release-exec-linux-SE_FW_x.y.z" — but tan flash runs on Windows, and the message tells a Windows customer their real install is not one.
Same defect class as #299/#310/#350: a verdict without the evidence for it.
2. The ATOC path is interpolated into the J-Link Commander script unquoted
python/tan/core/flash_plan.py:1404. With SETOOLS under a normal Windows location:
loadbin C:\Program Files\alif\setools\build\AppTocPackage.bin 0x8057ea50
J-Link Commander splits on whitespace, so the filename becomes C:\Program. -ExitOnError 1 (:1419-1420) means this fails loudly rather than mis-writing — which is the only reason this is not a blocker — but the customer gets SEGGER's parse error, not a tan diagnostic naming the space. tan generates this script now, so tan owns the quoting.
3. The probe-selection remediation points at the wrong discriminator
python/tan/commands/flash_cmd.py:1066-1069 says: "If jlink_serial is unset the script selects NO probe, which on a host carrying more than one J-Link cannot connect at all." That lands in the branch where a real SW-DP answered with the wrong ID.
On the bench this targets, pinning the serial is not sufficient: the AEN E8 probe and the GD32 bridge probe on a different board share the OEM-cloned serial 603000869, and JLinkExe selects only by serial with no USB-port selector. What separates them is the SW-DP ID — AEN E8 answers 0x4C013477, GD32 answers 0x0BE12477. A customer following this text sets flash_args.jlink_serial: 603000869 and still selects ambiguously between two boards, one of which their reservation does not cover.
#312 itself is respected — the re-enumeration case is a separate earlier branch that correctly says "not a wiring or probe-selection problem". Only this remediation sentence is wrong.
Acceptance criteria
missing_tool_message branches on os.path.isdir and names the exact candidate path(s) tried; it says "SETOOLS not found at <path>" rather than concluding what the directory is.
find_app_gen_toc tries app-gen-toc.exe on Windows, or the message states explicitly that only the Linux bundle is supported and why.
- The Commander script quotes every interpolated path, or
resolve_setools_dir refuses a path containing whitespace at resolve time and says so. A test covers a directory with a space.
- The wrong-DP-ID remediation names the SW-DP ID as the discriminator, and says a shared/cloned serial cannot be disambiguated by
jlink_serial alone.
Related: #353, #312.
Found while reviewing
feat/v06-batchat13891f1. Three small defects in the same area; grouped because they are one fix pass.1.
missing_tool_messageasserts a conclusion it did not checkpython/tan/core/setools.py:136-146emits "this does not look like an Alif Security Toolkit install" identically for:SETOOLS_DIRpointed at theapp-gen-tocbinary instead of its parent;find_app_gen_toc(:111-119) tests exactly one extension-less filename and neverapp-gen-toc.exe. The Linux-only bundle stance is deliberate and matchesdoctor_cmd'sSETOOLS_BUNDLE = "app-release-exec-linux-SE_FW_x.y.z"— buttan flashruns on Windows, and the message tells a Windows customer their real install is not one.Same defect class as #299/#310/#350: a verdict without the evidence for it.
2. The ATOC path is interpolated into the J-Link Commander script unquoted
python/tan/core/flash_plan.py:1404. With SETOOLS under a normal Windows location:J-Link Commander splits on whitespace, so the filename becomes
C:\Program.-ExitOnError 1(:1419-1420) means this fails loudly rather than mis-writing — which is the only reason this is not a blocker — but the customer gets SEGGER's parse error, not a tan diagnostic naming the space. tan generates this script now, so tan owns the quoting.3. The probe-selection remediation points at the wrong discriminator
python/tan/commands/flash_cmd.py:1066-1069says: "Ifjlink_serialis unset the script selects NO probe, which on a host carrying more than one J-Link cannot connect at all." That lands in the branch where a real SW-DP answered with the wrong ID.On the bench this targets, pinning the serial is not sufficient: the AEN E8 probe and the GD32 bridge probe on a different board share the OEM-cloned serial
603000869, andJLinkExeselects only by serial with no USB-port selector. What separates them is the SW-DP ID — AEN E8 answers0x4C013477, GD32 answers0x0BE12477. A customer following this text setsflash_args.jlink_serial: 603000869and still selects ambiguously between two boards, one of which their reservation does not cover.#312 itself is respected — the re-enumeration case is a separate earlier branch that correctly says "not a wiring or probe-selection problem". Only this remediation sentence is wrong.
Acceptance criteria
missing_tool_messagebranches onos.path.isdirand names the exact candidate path(s) tried; it says "SETOOLS not found at<path>" rather than concluding what the directory is.find_app_gen_toctriesapp-gen-toc.exeon Windows, or the message states explicitly that only the Linux bundle is supported and why.resolve_setools_dirrefuses a path containing whitespace at resolve time and says so. A test covers a directory with a space.jlink_serialalone.Related: #353, #312.