Hello Spen :-)
On Tue, Jan 15, 2013 at 5:45 PM, Spencer Oliver <[email protected]> wrote:
> I have been testing the current swd patches in gerrit and feel this is
> the better place at the moment to discuss issues until we are further
> along with the patches.
Yes this is more convenient :-)
> The following adapters have been tested with the same issues.
> luminary_icdi and JTAGkey2 with ARM-JTAG-SWD adapter
>
> 1. how to reset using srst.
Current RESET implementation is tied to JTAG it needs to be redefined
and this is the first on my list with internals redesign, I have made
some tests already and it can work on INTERFACE level...
At the momen you can use INTERFACE BITBANG functionality - that allows
to read and write designated port pin _mask_. Therefore you only need
to define SRST with "interface_signal srst mask" and then use it with
"interface_bitbang srst=hi/lo"...
I want to move these commands into interface subcommands, but this
requires internals redesign :-)
> 2. resume not working.
Did not test debugging yet as the speed was too slow. When the changes
are there I want to see the new mpsse interface and write TRANSFER and
BITBANG methods to be able to work with LibSWD - this could
dramaticaly improve the speed and the debug process will be possible
more conveniently :-)
> 3. cannot reconnect unless target is power cycled.
Yes I have noted that too. Maybe hardware reset is necessary.
According to ARM specification DAP RESET sequence should reset it into
initial state, but it does not work that way :-( Maybe someone with
more experience can have an idea on how to overcome this :-)
> 4. hla adapters (stlink and ti-icdi) do not work
This is good time Spen that we can cooperate :-) I have introduced
"Interface Features" that implement Transport for a given interface.
If interface is a generic one and provide Transfer and Bitbang methods
it can use generic transport drivers (such as LibSWD). But this is
also perfect match for HLA - your interface should define its own
feature set that can handle DAP operations on its own, so it does not
use generic LibSWD, but gets commands directly into the firmware and
returns the result. The outcome of this is the dramatically improved
preformance for HLA and still the possibility to use different
transports with a generic interfaces :-)
>From src/interface/feature:
#define OOCD_FEATURE_NAME_MAXLEN 50
#define OOCD_FEATURE_DESCRIPTION_MAXLEN 80
#define OOCD_FEATURE_ARM_DAP "oocd_feature_arm_dap"
typedef struct oocd_feature {
/** Feature name. */
char name[OOCD_FEATURE_NAME_MAXLEN];
/** Description is a one line feature summary. */
char description[OOCD_FEATURE_DESCRIPTION_MAXLEN];
/** Body points to feature contents. */
void *body;
/** Next points to next feature on the list. */
struct oocd_feature *next;
} oocd_feature_t;
>From src/transport/swd.h:
extern oocd_transport_t oocd_transport_swd;
extern const struct dap_ops *oocd_target_arm_dap_ops_swd;
>From src/transport/swd.c:
const struct dap_ops oocd_target_arm_dap_ops_swd_default = {
.is_swd = true,
.select = oocd_transport_swd_select,
.init = oocd_transport_swd_init,
.queue_idcode_read = oocd_transport_swd_queue_idcode_read,
.queue_dp_read = oocd_transport_swd_queue_dp_read,
.queue_dp_write = oocd_transport_swd_queue_dp_write,
.queue_ap_read = oocd_transport_swd_queue_ap_read,
.queue_ap_write = oocd_transport_swd_queue_ap_write,
.queue_ap_abort = oocd_transport_swd_queue_ap_abort,
.run = oocd_transport_swd_run,
};
I have documented all functions with Doxygen comments. Maybe I should
add some chapters to the Handbook..? :-)
> Tomek, any help on any of the above would be good. hla adapters not
> working can be ignored for the time being.
Try above hints, it should work :-) The only invasive change should be
the commit with comment "WARNING MAJOR UPDATES IN TRANSPORT
INFRASTRUCTURE". All other commits are designed to be backward
compatible and noninvasive, so if you have any problems please take a
look at changes introduced by that commit :-)
> One tweak i have made is that all my adapters tested use the inverse
> "RnW" logic, so i think we need to add support for this.
I think I have forseen that - please try "nRnW" signal name, it should
work together with "RnW" signal - this is the pair for driving the
output buffers on a direction change :-)
Good luck Spen, please write if you need any support, I am willing to
finish those tasks asap because I have other interesting works wating
:-)
Best regards :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
