Hello David, nice to hear from you! :-) On Mon, Oct 11, 2010 at 2:29 AM, David Brownell <davi...@pacbell.net> wrote: > From: David Brownell <dbrown...@users.sourceforge.net> > Subject: initial SWD transport (SWD infrastructure #2) > > This piggy backs on JTAG so it's not yet pretty, but that > seems unavoidable so far given today's OpenOCD internals. I'd > rather see JTAG and SWD be fully separate.
From what Ive seen on the patch listing swd is still in jtag directory, but its nice to hear that they should be separated :-) > # no JTAG regressions known. SWD UNTESTED ... once the SWD init > sequence is verified, I'd expect that Cortex-M3 to behave given > some SWD-aware driver (not yet provided). I am working on it - preferably FT2232 (KT-LINK) first, then RLink (Stm32Primer2).. but RLink can be more accessible on the STM32Primer2 boards.. and also needs some reverse engineering on the protocol. Which one of them do you think should be made working first to help SWD development and make it more accessible at the moment? > The debug adapter drivers can provide a simple SWD driver > struct with methods that kick in as needed (instead of JTAG). > So far just one adapter driver has been updated (not yet > ready to use or circulate). Do you mean to initialize the adapter or to perform all SWD operations? > The biggest issues are probably > - fault handling, where the ARM Debug Interface V5 pipelining > needs work in both JTAG and SWD modes and JTAG and SWD have their own ways of detecting/quering errors, but the sticky-bits part seems to be in fact similar, so maybe one error handling system could cover both JTAG and SWD..? > - missing rewrite of block I/O code to work on both transports > (vs current version, which is hard-wired to JTAG). > - omitted support to activate/deactivate SWO/SWV trace (this is > technically trivial, but configuring trace is NOT. Im not not yet at this point.. Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
