On Tue, Jan 18, 2011 at 1:18 PM, simon qian <simonqian.open...@gmail.com> wrote: > In my implementation of SWD in OpenOCD, trun is configured in configuration > files.
Nice! :-) OpenOCD has already great infrastructure implemented and it will surely allow many other transport implemented. Maybe it would be convenient to separate, create or wrap initialization functions and structures somehow to avoid using jtag_* functions in other transports..? > I have sucessfully run SWD under the tranport framework, but some changes: > 1. call jtag_register_commands in swd_select, because these commands are > needed when parsing configuration files Maybe this could be done by creating swd_register_commands based on jtag_register_commands, renaming it into core_register_commands or wrapping with transport_register_commands? > 2. ignore jtag calls in core.c and tcl.c in SWD mode. How these can be ignored? I think the best solution would be not to have any alien calls within specified transport, so the tranports are separate of each other, even when more than one transport it in use - this could allow for instance using JTAG/SWD and SPI for FPGA prototyping/development when SPI memory is directly programmed by cable and the same cable could use JTAG/SWD for debug. > 3. add queue_dp_scan to struct dap_ops, so that in arm_adi_v5.c, > dap_ops-> queue_dp_scan is called instead of adi_jtag_dp_scan. Great! And the queue is being used by existing infrastructure..? > 4. clear error registers: > In JTAG: > dap_queue_dp_write(dap, DP_CTRL_STAT, SSTICKYERR); > In SWD: > dap_queue_dp_write(dap, DP_ABORT, DAPABORT | STKERRCLR | WDERRCLR | > ORUNERRCLR); Wow, this is really nice and I was wondering how such high-level access could look - this one is very comfortable! :-) Simon, do you know how the command queue can be realized to replay all of the commands that are stored in a file (ie. something like svf player). Still I dont really understand how such "past" command can be executed from the longer queue with additional parameters such as error flags and if its possible - those flags must have its own structure to be put on the queue with the command? Do you have experience with such stuff? This is simple when executing commands at real time because error flags can be directly supplied into calling function, but when it is one of many commands queued, then after each step there must be some additional function checking for an error.. so how to filter out some resulting bits in a universal manner, or simply blindly replay the queue and stop when driver function returns error? We could also create high-level command for data transfer polling for potential transfer errors (they would consist of data phase and CTLSTAT register read to verify the sticky flags), or these should be done with external tcl scripts using simple hardcoded functions? Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
