simonqian.openocd wrote: > >> What I did is: > >> 1. add SWD drivers according to the specification > >> Versaloon firmware can do SWD re-transaction if SWD_ACK_OK is not > >> returned, of course there is a max retry count. > >What happens when the retry count expires? OpenOCD shows an error, > >but what state is the target in? > Actually, versaloon will resend automatically, no error will rise in > upper level.
Yes, in the normal case that is the perfect solution, but what happens when the retry count in the firmware is exceeded? > I can try to remove the resend code in Versaloon, and see what will > happen. I am interested also in the corner cases. > >> 2. didn't call JTAG specific functions in SWD mode, below is the list. > >> jtag_init_inner(which will run a device detect algorithm on JTAG), > >> tlr reset(because I didn't change the reset script) > >How does device detect and reset work using SWD? > For JTAG: > scan enough 1's after jtag reset and from the data read, IDs of all > target devices are listed. Ok. > For SWD: > dap_queue_idcode_read will return the SWD_ID, so that target device > can be detected. SWD supports connecting to a single device only, no chain? Ok. > reset is simply to control srst pin, but for jtag, if trst_with_tlr > is enabled, TLR is used. Ok, yes, quite similar. > >> adi_v5_swd.c maybe different, because actually it's originally > >> copied from adi_v5_jtag.c, and OpenOCD has some modification in > >> later commit in adi_v5_swd.c, and I didn't follow because original > >> code is stable. > >Can you say which commit your latest patch is based on? > I really can't remember that, it's more than 2 years ago. The date can also be used to find one commit where the patch applies cleanly. > But I can try to test it on the latest code in OpenOCD. Ok, but if the correct parent commit can be found it may be possible for git to do much of the work automatically. This is also a good reason to always create a git commit on a branch and use git format-patch to generate the patch, because such patches contain information about the previous versions of the changed files, which can then be trivially used to find which commit it was based on. > >> About sticky error handler, I use the same method as JTAG, the > >> difference is that when clear sticky error, use SWD method. > >Does this fit also SWD? > Actually, there is jtagdp_transaction_endcheck and > swddp_transaction_endcheck, which will check the stickyerr. > You can refer to swddp_transaction_endcheck, there is even some > broken code in old OpenOCD: > /* Danger!!!! BROKEN!!!! */ > adi_swd_scan_inout_check_u32(dap, SWD_DP_DPACC, > DP_CTRL_STAT, DPAP_READ, 0, &ctrlstat); > /* Danger!!!! BROKEN!!!! Why will jtag_execute_queue() fail here???? > R956 introduced the check on return value here and now Michael > Schwingen reports that this code no longer works.... > > https://lists.berlios.de/pipermail/openocd-development/2008-September/003107.html > */ Those comments are funny and sad at the same time. :) > I think SWD support should be added from high to low, This sounds good, and I also think this is the easier way. Of course it's good to keep in mind how libswd works on the lower level to reduce extra effort on both sides where possible. > some modification in my patch is only a work-around, but not a > solution. Versaloon driver can also be added into libswd, or > independent from libswd, it's not the vital point. Since the Versaloon firmware performs some of the tasks that libswd also does it may make most sense to have the Versaloon driver independent, but perhaps using the same transport API as libswd. Agree this is not a very important decision. > The vital problem is that even now, OpenOCD code is too much JTAG > dependent, so that it's not possible to add other transports, even > if the transport layer is ok. > I know which codes in OpenOCD are JTAG dependent. > So if we can somehow make these codes transport independent under > some common point of view, it will be easier for other to add their > drivers. Agree completely. I think it is best to make many small changes, then it is also easy to quickly find the common point of view on each change. Where do you suggest to start? Would the points that I commented on as perhaps suitable for immediate change in reply to Tomek's mail be a start? //Peter ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
