Upgrade Notes
- Update your boxes. The new flash and erase checks, the probe lock and the diagnosis run on
the box. Run
lager update --box <box-name>after you upgrade the CLI. A 0.51.0 CLI still works with an older box, and judges the flash from its output text. flashanderasecan now fail where they reported success. On J-Link, a flash that programmed nothing now exits 1 withFlash failed:. An erase that erased nothing exits 1 too. A script that relied on exit 0 will now stop at the real failure. Fix the cause that the output names, then run the command again.- J-Link must show evidence of a flash or an erase. A flash needs a
J-Link: Flash download:line (orO.K.) afterDownloading file. An erase needsErasing done.. If your target’s J-Link output does not contain these lines, setLAGER_JLINK_REQUIRE_EVIDENCE=0in the CLI’s environment. lager debug NET gdbserverexits 0 on a box whose gateway cannot tunnel. Version 0.50.2 exited 1 there, even with--no-tunnel. The command now starts the GDB server, prints a warning, and exits 0. It prints no address, because no debugger on this machine can reach the server. A script that must know this can read"gdb_port_reachable": falsefrom--json.- A second operation on one probe now waits. A
connect,memrd,reset,flashorerasethat arrives during another one on the same probe waits for it to finish. After 300 seconds it fails withDebug probe <serial> is busy. SetLAGER_PROBE_LOCK_TIMEOUT_Son the box to change the limit.
Features
- A failed J-Link flash tells you what else happened.
Diagnosis:lines list every other J-Link program that used the probe during the flash. On a DA1469x, they also tell you if the target reset during programming, and which reset it was. LAGER_JLINK_REQUIRE_EVIDENCE=0turns off the evidence check for a target whose J-Link output uses different wording. The CLI sends it with each flash and erase. A failure line still fails the command.gdbserver --jsonreportsgdb_port_reachableasfalsewhen no debugger on this machine can reach the GDB server.
Bug Fixes
lager debug NET flashprintedFlashed!when J-Link programmed nothing. J-Link printsDownloading filebefore it downloads the RAMCode that programs the flash. When that download failed, the CLI still counted the flash as done. The erase before the flash cleared the part, so the target stayed blank. The CLI now reads J-Link’s failure lines first, and requires J-Link’s evidence of a flash.- The cause: a second J-Link client on the probe. J-Link lets two programs open one probe,
and it does not stop them from interfering. The Lager Box ran a flash and a
connect,memrd,resetor Python script on the same probe at the same time. The box now runs one operation per probe at a time. - A probe that another program held gave a false success. J-Link answered
Selected interface (SWD) is not supported by the connected probe.and exited normally. Bothflashanderasethen reported success with nothing written or erased. They now fail on that line. - A J-Link that dropped off USB during a flash gave a false success. The box discarded the
error and returned no output, and the CLI printed
Flashed!. The flash now fails withJLinkExe exited mid-session:and the last line that J-Link printed. - A flash that failed on a DA1469x still reset the target. The box no longer resets the
target after a failed program, and it no longer prints
Target resetover a failure.
Known Limitations
- On an nRF5340 with J-Link V9.50, a plain
erasedoes not erase. J-Link printsErasing done.withErase: 0.000s, and the flash does not change. A range erase with--erase-startand--erase-sizeworks. See issue #618. - A J-Link verify failure does not fail the flash. A DA1469x reports a false
Verification failedon a correctly programmed part, so the CLI ignores these lines. See issue #617. - The probe lock orders requests, not whole commands. A
memrdthat you start during a flash can run between its erase and its program step, and read the erased flash.

