On 5/24/25 07:34, Tomas Vanek wrote:
Please be aware of *12.2 Preparing a Target before Flash Programming
*"""
The target device should be in well defined state before the flash
programming begins.
Always issue reset init before Flash Programming Commands. ...
I guess if we're willing to accept that this is "the only way", then
just doing it in the reset init event is sufficient.
It seems like it might be a good idea to yell at the user if they
attempt flash programming when the target is not in such a well-defined
state, but that's outside my pay grade on this one.
*So the Tcl event which should be issued before flash erase/write is
reset-init. With the exception of targets
with totally screwed reset.
The IMXRT is only mostly screwed...
Bafflingly, the external reset pin basically doesn't work when you're
trying to use a debugger. It does something and will in fact case the
CPU to "reboot" insofar as it will re-run the ROM bootloader, but trying
to halt the core afterward fails for reasons I cannot figure out.
Instead, you have to use Cortex-M sysresetreq which introduces other
problems. In effect, you end up relying on the watchdog to reset most
of the chip for you which leads to obvious problems if you've disabled
the watchdog.
The most reliable method is to assert POR_B, de-assert it, call for
sysresetreq via the core, then attempt to halt it. OpenOCD can't
currently do that easily since there's no good reset_config for it. I
have a little TCL routine that does it by frobbing the reset_config in
the middle of the process.
Unfortunately the Kinetis watchdog is so strict in checking the time
between writes in the switch-off sequence that we have to run a target
algo to meet the sequence timing.
If iMXRT has a similar watchdog then Tcl target memory writes will not work.
The IMXRT is similar in that respect. All three watchdogs (two
instances of one type and one instance of another) require a pretty
tightly-timed sequence of writes to disable them. In fact, I have yet
to figure out how to reliably disable one of them. Thankfully the
bootloader does it for me for my main application.
There is, however, another baffling feature that's essentially a
backdoor on the watchdogs. While the watchdogs have all this crazy
protection on them, the system reset controller just has a register you
can write to that disables resets from the watchdog from taking effect.
As far as I can tell, a single write to this register with the right
values completely neuters the watchdogs, though I am still testing.
It's not even a write-once or otherwise lockable register.
