On Mar 15, 2012 3:15 AM, "simonqian.openocd" <simonqian.open...@gmail.com>
wrote:
>
> Yes, I know how SRST should not be processed in DAP, but make the
> change you mentioned is too large for me to handle in OpenOCD. And it
> also risky because it affect too much in OpenOCD.
Ok then lets do it as you proposed if its already working :-)
> In vsprog, I have the similar interface layer, which processes all signals
> to the target. SRST control in vsprog is in GPIO module, for example:
> interfaces->gpio.config(0, GPIO_SRST, GPIO_SRST, 0, 0);
> interfaces->gpio.set(0, GPIO_SRST);
> There is of course jtag and swd function, and can be called like:
> interfaces->jtag_hl.ir(....);
> interfaces->jtag_hl.dr(....);
> interfaces->swd.transact(....);
> So it's very simple for me to add different transports and targets in
vsprog.
So we should place that reset implementation using interface bitbang..? The
main advantage of this solution is to create and operate on signals at
runtime..
> About double buffer operation in cortex-m targets.
> There are 2 buffers in working area of target chip, flash loader will do
> programming operations if one of them is filled with data. And while the
> flash loader is doing the programming, we can meanwhile download data
> into the other buffer. So if we select the right buffer size, we can get
the
> max speed. For stm32, as I test on versaloon, it's about 35KB/s.
So there is some code uploaded and executed on the target and that code use
ram buffers to store data for better efficiency..? Where can I read more
about this solution? Will it work with OpenOCD?
Best regards :-)
Tomek
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
