On Monday 22 February 2010, simon qian wrote: > 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
Right. The current incarnation of my transport-neutrality layer in the ADIv5 code -- which I'll post in a while -- continues the current expectation that such flags are automagically cleared as part of cleaning up after processing the transaction queue. That is, JTAG glue would do it the JTAG way (write to CSW), while SWD glue would do it the SWD way (write to ABORT register). An alternate strategy would be to have methods on the transport entity to clear those flags. (I'll sure be hoping you will give that SWD-related stuff a very careful review. I've certainly been looking at the monolithic patch you sent a while back. Between us, I expect we should be able to get serious progress on SWD in this release!!) > WAITb001 The WAIT response to a DPACC or APACC access on page4-16 > ... Same thing. But of course, the status handling in that code is quite a mess. Regardless, handling the WAIT status clearly needs to be transport-specific. > So ADIv5 code should know which mode it's in(JTAG or SWD) to perform > corrently. There's another issue you didn't mention: DP register addressing isn't the same. There's WCR, and CTRLSEL, for one thing ... and also RESEND vs SELECT. The same general strategy, I think, applies there too: all the operations which would need to access those registers need to be wrapped in transport-specific methods, so the JTAG code will know to do one thing, while SWD code knows to do a different thing. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
