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


Reply via email to