Re: [Openocd-development] arm-jtag-ew + swd
Well, the ARM-JTAG-EW is not an FT2232 device as far as I can tell -- it's supposed to be a JLink clone for IAR. I guess the answer is no then. Looks like the right thing is to get a real JLink. Thanks anyway! On Tue, Oct 18, 2011 at 1:52 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Tue, Oct 18, 2011 at 2:47 AM, Michael Ashton d...@gtf.org wrote: Hi, I'm wondering if anyone can say whether it's possible, or might ever be possible, to use the Olimex ARM-JTAG-EW with SWD in OpenOCD? I can't find any mention of SWD in arm-jtag-ew.c, but I'm not sure whether that really means anything. thanks! --Michael Driver is generic for FT2232 devices, you can play with some resistor/diode to make JTAG interface work as SWD :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info -- Quidquid latine dictum sit, altum viditur. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
You're right -- my mistake. The web page says: ARM-JTAG-EW emulates on low level the IAR Systems' J-LINK API so it works like normal J-LINK debugger, ... I took this to mean that they were emulating the USB protocol. But a footnote in the manual says -- DLL compatible means that we supply our own jlinkarm.dll. The original IAR-EW DLL will not work with the ARM-JTAG-EW device because ARM-JTAG-EW and IAR J-Link use different USB protocols. So that explains that then. The Olimex manual mentions SWD in the pinout table, so perhaps they have the necessary hardware already. Might give it a shot with libswd but I need to get moving on this project .. On Wed, Oct 19, 2011 at 8:52 AM, jim norris u17...@att.net wrote: Well, the ARM-JTAG-EW is not an FT2232 device as far as I can tell -- it's supposed to be a JLink clone for IAR Yes it is. It has an FT2232D chip in. If you open it up (and void the warranty!) you can see it. However, using the ARM-JTAG-EW to do SWD is not just a software change. As Tomek implied in the previous email, one needs to understand the pinouts. JTAG typically uses 5 pins, while SWD uses 2 pins. So there are some hardware ramifications when using a FT2232 device for SWD versus JTAG as typically found in most debuggers. -- Quidquid latine dictum sit, altum viditur. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
On Wed, Oct 19, 2011 at 4:53 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Oct 20, 2011 at 1:52 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Oct 20, 2011 at 1:49 AM, Peter Stuge pe...@stuge.se wrote: It might be really easy to make the device speak SWD. JLink specification is open, from what Ive seen it should be relatively easy to implement generic (tranfer/bitbang functions) driver for this device :-) I noticed that too. Segger's GDB server is Windows-only, which can be inconvenient. Their documentation for their USB protocol looks very complete. -- Quidquid latine dictum sit, altum viditur. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
On Wed, Oct 19, 2011 at 4:49 PM, Peter Stuge pe...@stuge.se wrote: Michael Ashton wrote: On Wed, Oct 19, 2011 at 8:56 AM, Laurent Gauch wrote: certainly olime waits on Segger JLINK SWD implementation in openocd to let say their arm jtag ew has swd certainly olime waits on Amontec JTAGkey-3 SWD implementation in openocd to let say their 2232 has swd ... Ha .. I see .. cheeky of them .. Well, I'm sending it back. --mpa Don't listen too much to Laurent's complaints. Of course he will be unhappy with competition. Which is certainly understandable :) It might be really easy to make the device speak SWD. Might be, but I needed to get something working quickly and reliably -- it's a commercial project. --mpa ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] arm-jtag-ew + swd
Hi, I'm wondering if anyone can say whether it's possible, or might ever be possible, to use the Olimex ARM-JTAG-EW with SWD in OpenOCD? I can't find any mention of SWD in arm-jtag-ew.c, but I'm not sure whether that really means anything. thanks! --Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] ADuC702x flash plugin patch
The attached patch makes the aduc702x flash plugin work for me with the
following setup:
* Olimex ARM-USB-OCD JTAG adapter
* Olimex ADUC-P7026 development board
* Cygwin
The changes are as follows:
* Flash bank setup made static
* Sector information now filled in -- GDB can now download code
* Erase and write routines fixed
* Block writing now supported (based on STR7X code)
* Note added to users guide about plugin command syntax
* Default target config file edited, with working area added
I haven't implemented the protection code -- in fact I can't see much use
for it on this device -- but it shouldn't be terribly difficult.
I'd love to hear how well this works for anyone else with a similar setup.
There are a few rough edges yet, the worst being that reset seems not to
work at all for this target, but I'm at least now able to download code to
it at reasonable speed.
--Michael Ashton d...@gtf.org
Index: src/target/target/aduc702x.cfg
===
--- src/target/target/aduc702x.cfg (revision 1337)
+++ src/target/target/aduc702x.cfg (working copy)
@@ -39,8 +39,12 @@
set _TARGETNAME [format %s.cpu $_CHIPNAME]
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME
+# allocate the entire SRAM as working area
+$_TARGETNAME configure -work-area-phys 0x1 -work-area-size 0x2000
+
## flash configuration
-flash bank aduc702x 0x8 0x1 2 2 0
+# only target number is needed
+flash bank aduc702x 0 0 0 0 0
## If you use the watchdog, the following code makes sure that the board
## doesn't reboot when halted via JTAG. Yes, on the older generation
Index: src/flash/aduc702x.c
===
--- src/flash/aduc702x.c(revision 1337)
+++ src/flash/aduc702x.c(working copy)
@@ -1,6 +1,7 @@
/***
* Copyright (C) 2008 by Kevin McGuire *
* Copyright (C) 2008 by Marcel Wijlaars *
+ * Copyright (C) 2009 by Michael Ashton *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
@@ -23,7 +24,7 @@
#endif
#include replacements.h
-
+#include time_support.h
#include flash.h
#include target.h
#include log.h
@@ -40,9 +41,14 @@
int aduc702x_erase(struct flash_bank_s *bank, int first, int last);
int aduc702x_protect(struct flash_bank_s *bank, int set, int first, int last);
int aduc702x_write(struct flash_bank_s *bank, u8 *buffer, u32 offset, u32
count);
+int aduc702x_write_single(struct flash_bank_s *bank, u8 *buffer, u32 offset,
u32 count);
+int aduc702x_write_block(struct flash_bank_s *bank, u8 *buffer, u32 offset,
u32 count);
int aduc702x_probe(struct flash_bank_s *bank);
int aduc702x_info(struct flash_bank_s *bank, char *buf, int buf_size);
int aduc702x_protect_check(struct flash_bank_s *bank);
+int aduc702x_build_sector_list(struct flash_bank_s *bank);
+int aduc702x_check_flash_completion(target_t* target, unsigned int timeout_ms);
+int aduc702x_set_write_enable(target_t *target, int enable);
#define ADUC702x_FLASH 0xf800
#define ADUC702x_FLASH_FEESTA (0*4)
@@ -67,8 +73,8 @@
typedef struct
{
- unsigned char tmp;
-} aduc702x_bank;
+ working_area_t *write_algorithm;
+} aduc702x_flash_bank_t;
flash_driver_t aduc702x_flash =
{
@@ -90,26 +96,42 @@
return ERROR_OK;
}
-/* flash bank aduc702x base size 0 0 target# */
+/* flash bank aduc702x 0 0 0 0 target#
+ * The ADC7019-28 devices all have the same flash layout */
int aduc702x_flash_bank_command(struct command_context_s *cmd_ctx, char *cmd,
char **args, int argc, struct flash_bank_s *bank)
{
- aduc702x_bank *nbank;
+ aduc702x_flash_bank_t *nbank;
- if (argc 6)
- {
- LOG_WARNING(incomplete flash_bank aduc702x configuration);
- return ERROR_FLASH_BANK_INVALID;
- }
+ nbank = malloc(sizeof(aduc702x_flash_bank_t));
- nbank = malloc(sizeof(aduc702x_bank));
- /* just warn that we are used to normally using 0x8 */
- if (bank-base != 0x8)
- {
- LOG_WARNING(Default base address is 0x8 on the ADuC7026!);
- }
+bank-base = 0x8;
+bank-size = 0xF800; // top 4k not accessible
+ bank-driver_priv = nbank;
+
+aduc702x_build_sector_list(bank);
+
+return ERROR_OK;
+}
+
+int aduc702x_build_sector_list(struct flash_bank_s *bank)
+{
+ //aduc7026_flash_bank_t *aduc7026_info = bank-driver_priv;
- nbank-tmp = 1;
- bank-driver_priv = nbank;
+int i = 0;
+u32 offset = 0
[Openocd-development] [PATCH] ADuC702x flash plugin
(Sorry if this shows up more than once -- I've just subscribed, and the
first attempt didn't seem to work.)
The attached patch makes the aduc702x flash plugin work for me with the
following setup:
* Olimex ARM-USB-OCD JTAG adapter
* Olimex ADUC-P7026 development board
* Cygwin
The patch makes the following changes:
* Flash bank setup made static
* Sector information now filled in -- GDB can now download code
* Erase and write routines fixed
* Block writing now supported (based on STR7X code)
* Note added to users guide about plugin command syntax
* Default target config file edited, with working area added
I haven't implemented the protection code -- in fact I can't see much use
for it on this device -- but it shouldn't be terribly difficult.
I'd love to hear how well this works for anyone else with a similar setup.
There are a few rough edges yet, the worst being that JTAG reset seems not
to work at all for this target (probably an easy fix), but I'm at least now
able to download code to it at reasonable speed.
--Michael Ashton d...@gtf.org
Index: src/target/target/aduc702x.cfg
===
--- src/target/target/aduc702x.cfg (revision 1337)
+++ src/target/target/aduc702x.cfg (working copy)
@@ -39,8 +39,12 @@
set _TARGETNAME [format %s.cpu $_CHIPNAME]
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME
+# allocate the entire SRAM as working area
+$_TARGETNAME configure -work-area-phys 0x1 -work-area-size 0x2000
+
## flash configuration
-flash bank aduc702x 0x8 0x1 2 2 0
+# only target number is needed
+flash bank aduc702x 0 0 0 0 0
## If you use the watchdog, the following code makes sure that the board
## doesn't reboot when halted via JTAG. Yes, on the older generation
Index: src/flash/aduc702x.c
===
--- src/flash/aduc702x.c(revision 1337)
+++ src/flash/aduc702x.c(working copy)
@@ -1,6 +1,7 @@
/***
* Copyright (C) 2008 by Kevin McGuire *
* Copyright (C) 2008 by Marcel Wijlaars *
+ * Copyright (C) 2009 by Michael Ashton *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
@@ -23,7 +24,7 @@
#endif
#include replacements.h
-
+#include time_support.h
#include flash.h
#include target.h
#include log.h
@@ -40,9 +41,14 @@
int aduc702x_erase(struct flash_bank_s *bank, int first, int last);
int aduc702x_protect(struct flash_bank_s *bank, int set, int first, int last);
int aduc702x_write(struct flash_bank_s *bank, u8 *buffer, u32 offset, u32
count);
+int aduc702x_write_single(struct flash_bank_s *bank, u8 *buffer, u32 offset,
u32 count);
+int aduc702x_write_block(struct flash_bank_s *bank, u8 *buffer, u32 offset,
u32 count);
int aduc702x_probe(struct flash_bank_s *bank);
int aduc702x_info(struct flash_bank_s *bank, char *buf, int buf_size);
int aduc702x_protect_check(struct flash_bank_s *bank);
+int aduc702x_build_sector_list(struct flash_bank_s *bank);
+int aduc702x_check_flash_completion(target_t* target, unsigned int timeout_ms);
+int aduc702x_set_write_enable(target_t *target, int enable);
#define ADUC702x_FLASH 0xf800
#define ADUC702x_FLASH_FEESTA (0*4)
@@ -67,8 +73,8 @@
typedef struct
{
- unsigned char tmp;
-} aduc702x_bank;
+ working_area_t *write_algorithm;
+} aduc702x_flash_bank_t;
flash_driver_t aduc702x_flash =
{
@@ -90,26 +96,42 @@
return ERROR_OK;
}
-/* flash bank aduc702x base size 0 0 target# */
+/* flash bank aduc702x 0 0 0 0 target#
+ * The ADC7019-28 devices all have the same flash layout */
int aduc702x_flash_bank_command(struct command_context_s *cmd_ctx, char *cmd,
char **args, int argc, struct flash_bank_s *bank)
{
- aduc702x_bank *nbank;
+ aduc702x_flash_bank_t *nbank;
- if (argc 6)
- {
- LOG_WARNING(incomplete flash_bank aduc702x configuration);
- return ERROR_FLASH_BANK_INVALID;
- }
+ nbank = malloc(sizeof(aduc702x_flash_bank_t));
- nbank = malloc(sizeof(aduc702x_bank));
- /* just warn that we are used to normally using 0x8 */
- if (bank-base != 0x8)
- {
- LOG_WARNING(Default base address is 0x8 on the ADuC7026!);
- }
+bank-base = 0x8;
+bank-size = 0xF800; // top 4k not accessible
+ bank-driver_priv = nbank;
+
+aduc702x_build_sector_list(bank);
+
+return ERROR_OK;
+}
+
+int aduc702x_build_sector_list(struct flash_bank_s *bank)
+{
+ //aduc7026_flash_bank_t *aduc7026_info
