I collect some of the differences in ADIv5 between JTAG and SWD: 1. Clear Error Flag in Control/Statis: See ARM ADIv5, 6-16. Clearing the sticky error flags in the Control/Status Register In the Control/Status Register, the sticky error flags are: •STICKYERR, bit[5] •STICKCMP, bit[4] •STICKORUN, bit[1] The descriptions of these bits in Table6-7 on page6-10 indicate the condition that sets each bit to 1. When one of these bits is set to 1, a write of 0 to that bit is ignored. The method of clearing these bits to 0 is different for the JTAG-DP and the SW-DP: On a JTAG-DP Write 1 to the appropriate bit of this register. For example, if the STICKYERR flag, bit[5], is set to 1 then you must write 1 to bit[5] to clear the flag to 0. On a SW-DP Write 1 to the appropriate CLR field of the AP Abort Register, see The AP Abort Register, ABORT on page6-6: •to clear STICKYERR to 0, write 1 to the STKERRCLR field, bit [2] •to clear STICKYCMP to 0, write 1 to the STKCMPCLR field, bit [1] •to clear STICKYORUN to 0, write 1 to the ORUNERRCLR field, bit [4]. 2. swjdp->ack has different value For JTAG(See 4-14): ResponseACK[2:0] encodingSee: OK/FAULTb010 The OK/FAULT response to a DPACC or APACC access on page4-15 WAITb001 The WAIT response to a DPACC or APACC access on page4-16 For SWD(See 5-7): OK: 0b001 WAIT: 0b010 FAULT: 0b100 3. different sequence should be outputed on TMS/SWDIO 4. RDBUFF For JTAG(See 4-16): Register accesses can be pipelined, because a single DPACC or APACC scan can return the result of the previous read operation at the same time as shifting in a request for another register access. At the end of a sequence of pipelined register reads, you can read the DP RDBUFF Register to shift out the result of the final register read. For SWD(See 5-11): Read accesses to the AP are posted. This means that the result of the access is returned on the next transfer. If the next access you have to make is not another AP read then you must insert a read of the DP RDBUFF Register to obtain the posted result, see The Read Buffer, RDBUFF on page6-17. 5. different way to read ID See 6-8 6. driver layer API(JTAG/SWD)
So ADIv5 code should know which mode it's in(JTAG or SWD) to perform corrently. 2010/2/22 David Brownell <davi...@pacbell.net> > Archives are in the Berlios and SourceForge "files" areas. > > Mainline git is now tagged as "0.5.0-dev"; the merge window > is open. If we need a bugfix release, it'll branch off from > the commit with the "0.4.0" tag. > > I've committed a few patches from my pending queue, most > notably: > > - Making the ARMv7m stuff use "struct arm" so that > the Cortex-M semihosting support can use most of > the existing semihosting code (except for the small > bit which will need to know it's using a different > entry mechanism > > - The "cleanup" portion of the ADIv5 work, which will > help with the SWD support. (Sanity checked on both > M3 and A8 Cortex cores.) > > We're not sure who will be release manager for 0.5.0 ... but > we do know it's someone else's turn!! If we keep to the kind > of schedule we've had so far, one might anticipate this release > ships no sooner than the end of April. > > I'm not sure what else will be merging soon. There are some > feature patches which have been posted to the list, and held > until the 0.5 window. And Spen has a bunch of performance > work upcoming too (not all for MIPS, ISTR). Clearly we want > to see major progress on SWD during this release cycle ... but > it's not ready yet, and I'm not sure what other stuff will be > happening. I guess this means 0.5.0 will surprise us all! :) > > - Dave > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- Best Regards, SimonQian http://www.SimonQian.com
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
