Martin,
On 24/05/2025 04:58, Brandon Martin wrote:
It would be handy for the FLEXSPI if there were target events for
non-GDB initiated flash erase start/end and write start/end since it
would allow deferring disabling of watchdogs, which are chip-specific,
to the relevant TCL scripts. Is that something that folks would be
amenable to me adding? Does that already exist (I don't see it)?
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. ...
If you use Programming using GDB, the target is prepared automatically
in the event gdb-flash-erase-start
The Tcl script program calls reset init explicitly. *
"""
*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 Kinetis flash driver, at least, already has to handle some of
this. It has multiple "watchdog algorithms" and tries to match them up
heuristically. It can reasonably do this to some degree because all
Kinetis parts have a similar memory map, and there are only a few
different watchdogs across the whole line.
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 FLEXSPI is used in parts ranging from the smallest of the iMXRT
series (Cortex-M7) all the way up to some rather large iMX application
processors (multi-core Cortex-A7x). While the current driver has only
been tested on IMXRT1020 (though probably works on all of the iMXRT
parts), I'd like to avoid getting into unrelated, chip-specific stuff
that is known to not be chip-agnostic within the flash driver code
itself if possible.
It does look like all of the iMXRT parts have the same set of
watchdogs mapped in the same places, so if we knowingly restrict the
driver to just iMXRT (which are probably the most useful parts in the
context of openocd), then this may be a non-issue.
--
Brandon Martin
I agree it would be nice to have the watchdog handling optional. For the
beginning one option no wdog handling, the second iMXRT related.
Tomas