Yes, it won't be much change in Versaloon driver. What I concern is not Versaloon driver, but the multi-interface framework.
There is an error, what I mean should be swd_add_swdio_seq not swd_add_tms_seq. Under a generic multi-interface framework, an interface-related function can only be called when the interface is enabled. For example, if JTAG is enabled, jtag_* can be called, and if SWD is enabled, swd_* can be called. So dap_to_swd should call jtag_add_tms_seq or swd_add_swdio_seq according to the different dap mode, although the code may be the same. It will gain the maximum compatibility. 2010/3/3 David Brownell <davi...@pacbell.net> > On Tuesday 02 March 2010, simon qian wrote: > > For JTAG operation: > > JTAG_Initialize > > dap_to_jtag --> jtag_add_tms_seq > > ...... > > JTAG_Finialize > > Where those "Finalize" steps -- swapping transport hooks -- are > not yet available. > > > > For SWD operation: > > SWD_Initialize > > dap_to_swd -> jtag_add_tms_seq > > ...... > > SWD_Finialize > > ... ditto. > > > Note also that initializing into SWD mode vs JTAG mode is a > different mess ... one that I've not yet thought through > (and thus, obviously, not coded). > > One minimalist notion would be to expect target config files to > continue using "jtag newtap" ... so they wouldn't change much at > all ... beyond maybe a "this "TAP" *can* use SWD" assertion or, > as with LPC11xx and LPC13xx, *must* use SWD... > > > Then there'd be something like a "dap mode swd" command that > would cause initialization to go the SWD route (and instist > there's only one target) instead of the JTAG route .. it'd > need to set up WCR too, of course, and verify that it's using > either a dual-mode (JTAG/SWD) or SWD-only debug adapter. > > (Similar solution: "interface mode swd", "interface mode jtag", > and so on. It ought to be possible to switch back and forth...) > > > > Shouldn't it use swd_add_tms_seq in SWD operation? > > What specifically are you getting at there ... the fact > that adapter primitives are currently "jtag_*()" calls > so using them with SWD will lead to confusion? > > I figure we can add swd_*() calls easily enough. > > Other than link resets, I hadn't thought SWD operations > would need to spit bit sequences out TMS/SWDIO except > as part of implementing register access ... and those > should be hidden inside calls like swd_register_read() > or swd_register_write(), along with the magic "now use > SWDIO as an INPUT" (or OUTPUT) operation. > > And the dap_to_swd() call should work OK as a link reset > when called from SWD code (as part of fault recovery). > > - Dave > > p.s. I suspect you an pretty much implement the lowlevel TMS_SEQ > support right away for Versaloon. It's likely only minor > tweakage to your current code. > -- Best Regards, SimonQian http://www.SimonQian.com
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
