Re: [OpenOCD-user] MIMXRT5xx: Handling CSW resets

[Antonio B. <bor...@gm...>]

On Tue, Nov 11, 2025 at 8:12 PM Nathan Marshall <npm...@gm...> wrote:
>
> Hello all,
>
> I'm trying to work with a platform targeting the MIMXRT533, and I'm coming up against a perceived limitation of OpenOCD that I wanted to get advice on. I'm trying to enable debug mode which requires writing to the command and status word (CSW, base address 0x4010f000) register with  CSW[RESYNCH_REQ] = 1 and  CSW[CHIP_RESET_REQ] = 1 which I do with mww 0x4010f000 0x21.This causes the device to reset as expected, and then there are other steps in the process that need to be executed according to the datasheet to fully enable debug mode. However, since this first register write causes a reset that OpenOCD does not expect, I get:
>
> "Error: Failed to write memory at 0x4010f004"

Hi,
OpenOCD does not expect the target to become not responsive after a write.
But you can use the Tcl command `catch` to catch the error and handle
it in your script.
Also, to prevent OpenOCD to poll the target until it gets on again,
you can halt polling while write, then wait to let the SoC restart
before reactivating the polling
poll off
catch {mww 0x4010f000 0x21}
sleep 1000
# probably here you need to reconnect the adapter to the target, it
depends on MIMXRT533. You can try with
#       catch {dap init}
#       catch {[dap names] apid 0}
poll on

If you are using SWD, I expect you have no other options, because a
write through SWD should require a following dummy read to get the ACK
status. Probably the address of the error at write+4 is simply due to
the address autoincrement that gets associated with the operation of
reading the ACK.
If you are using JTAG, then OpenOCD allows you to "manually" shift the
command in the JTAG chain. Probably you can inject a write through the
commands irscan/drscan, but it's not trivial. If the Tcl code snippet
above works for you, just use it.

Regards
Antonio

>
> Which indicates that OpenOCD is trying to access some memory beyond what I need (I assume for caching purposes?). This fails since the device is in reset. It seems that OpenOCD needs a special memory write command that expects a subsequent hardware reset to occur for this kind of use case. This isn't the first time I've had this issue. I had a similar problem when trying to define a custom NVIC reset process for a DA1469x platform. Is there a feature already in OpenOCD that I'm missing that could accommodate this use case, or would that require a new feature to be added?
>
> Thanks in advance,
> Nathan
> _______________________________________________
> OpenOCD-user mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openocd-user