pyocd flash big image is too slow for RT1060

hi @flit,

We are using pyocd as the major flash tool for our sdk application develop and testing. Thanks working on this excellent tool!
We used gdbserver and gdb to load applications , and added timeout handler for pyocd gdbserver process to prevent pyocd is hang there.
You can see below logs that the flash programming is failed due to pyocd exceed max timeout 300s.
Sometimes it can success withinn 2mintues, sometimes it cannot.
Do you known how to improve the flash programming performance?

[2021-09-07 15:23:09,718 INFO] gdbserver: "c:\\program files\\python39\\python.exe" -m pyocd gdbserver --no-wait --port 6100 -u 02290000016dc16200000000000000000000000097969905 -O semihost_console_type=console -O keep_unwritten=false
[2021-09-07 15:23:11,234 INFO] C:/PROGRA~2/GNUARM~1/102020~1/bin/AR470E~1.EXE --exec C:/Dpc/binary/ota_demo_wifi_nxp.elf --silent
[2021-09-07 15:23:11,272 INFO] (gdb) target remote localhost:6100
[2021-09-07 15:23:13,482 INFO] (gdb) monitor reset --halt
[2021-09-07 15:23:13,682 INFO] (gdb) monitor halt
[2021-09-07 15:23:14,448 INFO] (gdb) load
[2021-09-07 15:28:11,280 WARNING] pid: 12720 exceeded timeout[Timeout=300(s)], force killed
[2021-09-07 15:28:11,342 WARNING] pid: 12416 exceeded timeout[Timeout=300(s)], force killed
[2021-09-07 15:28:11,357 ERROR] Loading section boot_hdr, size 0xa0 lma 0x60040000

Loading section .interrupts, size 0x400 lma 0x60040400

Loading section .text, size 0x10ae60 lma 0x60040800

Loading section .ARM, size 0x8 lma 0x6014b660

Loading section .init_array, size 0x8 lma 0x6014b668

Loading section .fini_array, size 0x4 lma 0x6014b670

Loading section .data, size 0x2a0c lma 0x6014b674

Loading section .ncache.init, size 0xd0 lma 0x6014e080

Remote communication error.  Target disconnected.: Not a directory.


[2021-09-07 15:28:11,379 INFO] Debug session is closed!
[2021-09-07 15:28:11,379 ERROR] gdbserver console: 
0000854:INFO:board:Target type is mimxrt1060
0000886:INFO:dap:DP IDR = 0x0bd11477 (v1 MINDP rev0)
0000902:INFO:ap:AHB-AP#0 IDR = 0x04770041 (AHB-AP var4 rev0)
0000949:INFO:rom_table:AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00fd000 (designer=00e part=88c)
0000949:INFO:rom_table:[0]<e00fe000:ROM class=1 designer=43b part=4c8>
0000949:INFO:rom_table:  AHB-AP#0 Class 0x1 ROM table #1 @ 0xe00fe000 (designer=43b part=4c8)
0000986:INFO:rom_table:  [0]<e00ff000:ROM class=1 designer=43b part=4c7>
0000986:INFO:rom_table:    AHB-AP#0 Class 0x1 ROM table #2 @ 0xe00ff000 (designer=43b part=4c7)
0001002:INFO:rom_table:    [0]<e000e000:SCS v7-M class=14 designer=43b part=00c>
0001002:INFO:rom_table:    [1]<e0001000:DWT v7-M class=14 designer=43b part=002>
0001002:INFO:rom_table:    [2]<e0002000:FPB v7-M class=14 designer=43b part=00e>
0001018:INFO:rom_table:    [3]<e0000000:ITM v7-M class=14 designer=43b part=001>
0001065:INFO:rom_table:  [1]<e0041000:ETM M7 class=9 designer=43b part=975 devtype=13 archid=4a13 devid=0:0:0>
0001071:INFO:rom_table:  [2]<e0042000:CTI class=9 designer=43b part=906 devtype=14 archid=0000 devid=40800:0:0>
0001071:INFO:rom_table:[1]<e0040000:TPIU M7 class=9 designer=43b part=9a9 devtype=11 archid=0000 devid=ca1:0:0>
0001087:INFO:rom_table:[2]<e0043000:TSGEN class=15 designer=43b part=101>
0001087:INFO:target_imxrt:IMXRT Boot Mode: Internal Boot
0001087:INFO:cortex_m:CPU core #0 is Cortex-M7 r1p1
0001149:INFO:cortex_m:FPU present: FPv5-D16-M
0001149:INFO:dwt:4 hardware watchpoints
0001149:INFO:fpb:8 hardware breakpoints, 1 literal comparators
0001171:INFO:gdbserver:Semihosting will be output to console
0001566:INFO:gdbserver:GDB server started on port 6100 (core 0)
0003544:INFO:gdbserver:Client connected to port 6100!
0003729:INFO:target_imxrt:IMXRT Boot Mode: Internal Boot
0003729:INFO:target_imxrt:IMXRT Boot Device: 0
[---|---|---|---|---|---|---|---|---|----]
[0005018:INFO:target_imxrt:IMXRT Boot Mode: Internal Boot
0005033:INFO:target_imxrt:IMXRT Boot Device: 0
===============

Start with the pyOCD gdbserver flow and the target_imxrt logging shown for mimxrt1060, then reproduce the GDB load operation with the reported image. Compare successful and timed-out flash attempts; done means the cause of the slow or intermittent programming is identified and the operation no longer exceeds the reported 300-second timeout.