Re: Target scriptable events for non-gdb flash start/end

[Brandon M. <lis...@mo...>]

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.