On 12.03.2018 21:53, Christopher Head wrote:
On March 10, 2018 11:25:15 PM PST, Tomas Vanek via OpenOCD-devel
<openocd-devel@lists.sourceforge.net> wrote:
I wouldn't call this case as an obscure one. The reason could be
insufficient device clock rate,
not very high adapter_khz. Anyway all these cases could be solved by
configuring
the device properly.
I don’t think this is related to device clock speed. You will get a WAIT if
there is a bus stall, and Flash programming is self timed. So I think it
depends on the 16 (typical) to 100 (maximum) microsecond word programming time.
If you can deliver 35 bits (length of a DRSCAN) plus the TMS transitions within
the word programming time, then you will get a WAIT reply.
You're right that self-timed flash write takes most of required time.
Bus transport should
take just one or two bus cycles (the second for clock sync). It is quite
different when using algo.
One more concern: If programming by algo is usable on SWD only, JTAG
users should
set WORKAREASIZE to zero. But algos are used for verify, blank check
and
external memories as well.
This may impose a big penalty...
Yes, this is unfortunate. The verify algorithm works fine for me, but of course
it is a synchronous, rather than asynchronous, algorithm, so any silicon
erratum exposed by bus arbitration or other weirdness would not apply there.
In any case, 4463 makes this change. I get one DAP WAIT, but no more, with my
FTDI at 2M, and programming works fine and verifies properly
Have you noticed programming speed?
For testing I connected STM32F722-nucleo and STM32F413-nucleo to one
JTAG chain from FT2232.
I configured 128 MHz clock in F7 reset-init
(http://openocd.zylin.com/4464) a lowered max adapter_khz to 3000
as my old FT2232C does not work well @ 6000 khz.
With algo:
> reset init
...
> adapter_khz
adapter speed: 3000 kHz
> dap memaccess
memory bus access delay set to 8 tck
> targets f7.cpu
> flash write_image 64kib.bin 0x08020000
wrote 65536 bytes from file 64kib.bin in 0.743568s (*86*.071 KiB/s)
> targets f4.cpu
> flash write_image 64kib.bin 0x08020000
wrote 65536 bytes from file 64kib.bin in 0.763147s (83.863 KiB/s)
Now with your patch and WORKAREASIZE 0 (both devices performs very
similar so I list just F722):
> reset init
...
> adapter_khz
adapter speed: 3000 kHz
> dap memaccess
memory bus access delay set to 8 tck
> flash write_image 64kib.bin 0x08040000
device id = 0x10006452
flash size = 512kbytes
not enough working area available(requested 76)
no working area available, can't do block memory writes
couldn't use block writes, falling back to single memory accesses
DAP transaction stalled (WAIT) - slowing down
wrote 65536 bytes from file 64kib.bin in 2.583704s (*24*.771 KiB/s)
However if you set longer memory access delay manually:
> dap memaccess 31
memory bus access delay set to 31 tck
> flash write_image 64kib.bin 0x08070000
not enough working area available(requested 76)
no working area available, can't do block memory writes
couldn't use block writes, falling back to single memory accesses
wrote 65536 bytes from file 64kib.bin in 0.962217s (*66*.513 KiB/s)
I got much worse results with DAP WAIT on a slow old Intel Atom single
core industrial PC:
speed as slow as 3.618 KiB/s (without wait 48.723 KiB/s).
FT2232 SWD transport (F7 only):
> reset init
...
> adapter_khz
adapter speed: 3000 kHz
> flash write_image 64kib.bin 0x08060000
device id = 0x10006452
flash size = 512kbytes
not enough working area available(requested 76)
no working area available, can't do block memory writes
couldn't use block writes, falling back to single memory accesses
SWD DPIDR 0x5ba02477
Failed to write memory at 0x0806006c
error writing to flash at address 0x08000000 at offset 0x00060000
Too fast, DAP WAIT is an error on FTDI/SWD.
> adapter_khz 1500
adapter speed: 1500 kHz
> flash write_image 64kib.bin 0x08070000
not enough working area available(requested 76)
no working area available, can't do block memory writes
couldn't use block writes, falling back to single memory accesses
wrote 65536 bytes from file 64kib.bin in 0.734222s (87.167 KiB/s)
Works. 46 SWCLK cycles / 1.5 MHz = 30.6 usec > t_flash
And finally ST-Link with original adapter_khz values:
> reset init
...
adapter speed: 4000 kHz
> flash write_image 64kib.bin 0x08030000
not enough working area available(requested 76)
no working area available, can't do block memory writes
couldn't use block writes, falling back to single memory accesses
wrote 65536 bytes from file 64kib.bin in 9.900800s (6.464 KiB/s)
Really slow in comparison to 110.128 KiB/s with algo.
Your change really speed-up non-algo flashing. Unfortunately WAIT handling
on dumb adapters is far from effective and manual setting of extra
memaccess cycles
heavily depends on the flash timing and this may vary with the flash
wear out/temperature/whatever.
(at least, it does once I work around the fact that my nasty multi target
hacks have gone from necessary to counterproductive).
BTW http://openocd.zylin.com/4295 is finally merged so I hope there is
no need for "nasty multi target hacks".
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
