BlackMark
77dd45aeca
--update-loader works by entering copies of the *new* image and letting them rewrite the resident. Those copies speak the link they were built for, but the host went on knocking with the session's baud and backend — the resident's. Where the image changed either, the staging copy was installed and then never answered: resident untouched, and on a 1 KiB tiny the staging slot is the whole application region, so the application was already gone. The wire cannot be probed for it. 512 bytes of position-independent code carry no header saying what rate they were built for, so the operator declares it: --staged-baud and --staged-autobaud, applied from the jump into the staging copy onward. Retuning goes through the open port — SetCommState or tcsetattr on the live handle, never a reopen — because a DTR pulse would reset the copy being talked to. Undeclared against a changed link it still cannot work, but the error now names that as the cause instead of reporting the bare activation timeout that sent the operator looking at wiring. The README's idempotence claim needed the same qualification: from step 2 a re-run must reach the new image, and after step 3 word 0 points at the staging copy, so on a patched-vector part the resident's link reaches nothing at all. Found on an ATtiny13A, where two controls differing only in the activation window updated cleanly and so isolated the link as the variable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>