> andreas> No I mean TARGETID as defined by ADIv5.2, which must be known to be > able to select a device on a multidrop SWD link.
Ok, i see the confusion. The TARGETID - as define by ARM, is identical to the JTAG-TAP-ID in style and format, thus in my mind the TARGETID = TAPID, but that is not the case because the DAP also has a TAPID … Duane> Bottom line: Are you ok with putting the DAP structure in the TAP structure as the first step? andreas> No, I'm not even OK with the DAP *pointer* that's currently there. Hmm - I must have been blind - I did not see that. what if I did this: use exactly that existing DAP structure pointer and remove the DAP STRUCTS from all other places. For example the Cortex_M has both a POINTER and a STRUCT, the STRUCT would go away. duane> Then - future: Create a TAP operations structure … full of pointers … it would default to JTAG tap modes, but could then be over-ridden later. andraes> Overridden with what? The TAP operations are necessarily implemented by a JTAG interface (via some convoluted wrappers to handle the complete scan chain... and queuing, yuk!). A DAP object can never implement a TAP. (A JTAG-AP, connected to a DAP, could however implement a scan chain consisting of a number of TAPs. But the DAP itself can't.) I think I am not describing it well what I mean is method, or operation, or interface structure. If the operational goal is this: I want TAP (X) to goto IR state (Y), and shift data bits (Z) in and out. The function pointer that knows how to do that - is found via this structure chain TARGET -> TAP -> SCAN_CHAIN_HEAD -> OPS_POINTER -> FUNCTION_PTR . All of these function pointers should take a “TAP” pointer as parameter #1 (aka: the fake C++ this pointer) andraes> I think you're after the problem caused by the lack of a scan_chain object (provided by a JTAG interface), with a pointer to it from each TAP in the chain. Yea, you are probably correct, see above -duane ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
