Re: [Openocd-development] [PATCH] CORTEX A8: Fix broken CPU identification
Hi Daniel, At 16:43 11/02/2011 +0100, Daniel Bäder wrote: S3CPC100 from Samsung is also detected as imx51 with this patch. Without this patch it works. May I ask which S5PC100 platform are you working with? Thanks, Nick Pelling ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] dsp568013 - switching/disabling taps
> > you can try configure with "--enable-verbose-jtag-io". All the jtag > input/output is done in interface.c. > I'm assuming this will help us see what is shifted in during the irscan commands. Any ideas on how to configure OpenOCD to handle the tap switching? Our current method does not handle the case when tapdisable is called. The disable functions are empty because they are just used to signal OpenOCD that one tap is disabled with the other is enabled. Phil Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] dsp568013 - switching/disabling taps
Hello,
you can try configure with "--enable-verbose-jtag-io". All the jtag
input/output is done in interface.c.
Regards,
Mathias
Am 15.02.2011 02:28, schrieb Rodrigo Rosa:
> Hi,
>
> We've been trying to communicate via JTAG (through a signalyzer H2)
> with a freescale 568013.
> Modifying the code for the dsp56321 we were able to communicate with
> our chip. It has two taps, a MASTER tap and a CORE tap.
>
> The default tap is the MASTER tap, and by default the CORE tap is
> disabled. There is a command to switch from the MASTER tap to the CORE
> tap and vice versa. Since it is a switch, only ONE tap is connected at
> a time.
> We need to make openocd know that the command that switches from
> MASTER to CORE disables MASTER (and the command to switch from CORE to
> MASTER disables CORE).
> The config file (see below) shows the hack we are currently using
> (empty disable functions).
>
> #-
> #-
> # Script for freescale DSP568013
> #
> source [find interface/signalyzer-h2.cfg]
>
> if { [info exists CHIPNAME] } {
>set _CHIPNAME $CHIPNAME
> } else {
>set _CHIPNAME dsp568013
> }
>
> if { [info exists ENDIAN] } {
>set _ENDIAN $ENDIAN
> } else {
> # this defaults to a big endian
>set _ENDIAN big
> }
>
> if { [info exists CPUTAPID ] } {
>set _CPUTAPID $CPUTAPID
> } else {
> # force an error till we get a good number
>set _CPUTAPID 0x01f2801d
> }
>
> #jtag speed
> adapter_khz 10
>
> #has only trst
> reset_config trst_only
>
> #MASTER tap
> jtag newtap $_CHIPNAME chp -irlen 8 -ircapture 1 -irmask 0x03
> -expected-id $_CPUTAPID
>
> #CORE tap
> jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0x03 -disable
> -expected-id 0x02211004
>
> #target configuration
> set _TARGETNAME $_CHIPNAME.cpu
> #target create $_TARGETNAME dsp5680xx -endian $_ENDIAN -chain-position
> $_TARGETNAME
>
> #select CORE tap by modifying the TLM register.
> #to be used when MASTER tap is selected.
> jtag configure $_TARGETNAME -event tap-enable "
> irscan $_CHIPNAME.chp 0x05;
> drscan $_CHIPNAME.chp 4 0x02;
> jtag tapdisable $_CHIPNAME.chp;
> "
>
> #select MASTER tap by modifying the TLM register.
> #to be used when CORE tap is selected.
> jtag configure $_CHIPNAME.chp -event tap-enable "
> irscan $_TARGETNAME 0x4;
> drscan $_TARGETNAME 4 0x1;
> jtag tapdisable $_TARGETNAME;
> "
>
> jtag configure $_TARGETNAME -event tap-disable {
> }
>
> jtag configure $_CHIPNAME.chp -event tap-disable {
> }
>
> #working area at base of ram
> #$_TARGETNAME configure -work-area-virt 0
>
> #-
> #-
>
> The tap seems to switch. After switching we can get what we believe is
> the CORE tap's IDCODE by executing:
>
>> scan_chain
>TapName Enabled IdCode Expected IrLen IrCap IrMask
> -- --- -- -- - - --
> 0 dsp568013.chp Y 0x01f2801d 0x01f2801d 8 0x01 0x03
> 1 dsp568013.cpu n 0x 0x02211004 4 0x01 0x03
>> jtag tapenable dsp568013.cpu
> JTAG tap: dsp568013.chp disabled
> JTAG tap: dsp568013.cpu enabled
> 1
>> scan_chain
>TapName Enabled IdCode Expected IrLen IrCap IrMask
> -- --- -- -- - - --
> 0 dsp568013.chp n 0x01f2801d 0x01f2801d 8 0x01 0x03
> 1 dsp568013.cpu Y 0x 0x02211004 4 0x01 0x03
>> irscan dsp568013.cpu 0x2
>> drscan dsp568013.cpu 32 0
> 02211004
>>
>
> Switching back to the MASTER tap does not seem to work correctly.
> After switching to the CORE tap and back to the MASTER tap we cannot
> execute IDCODE successfully.
> We get the following on telnet:
>
>> jtag tapenable dsp568013.chp
> JTAG tap: dsp568013.cpu disabled
> JTAG tap: dsp568013.chp enabled
> 1
>> irscan dsp568013.chp 0x02
>> drscan dsp568013.chp 32 0
>
>> drscan dsp568013.chp 32 0
>
>> drscan dsp568013.chp 32 2
> 0004
>
> looks like the tap is working in BYPASS. if we run "pathmove RESET"
> everything works fine again:
>
>> pathmove RESET
>> irscan dsp568013.chp 0x02
>> drscan dsp568013.chp 32 0
> 01F2801D
>
> What is the correct way to do the switching?
>
> Also, is there any way to get irscan to show what was shifted in?
>
> Thanks!
>
> --
> Rodrigo.
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] dsp568013 - switching/disabling taps
Hi,
We've been trying to communicate via JTAG (through a signalyzer H2)
with a freescale 568013.
Modifying the code for the dsp56321 we were able to communicate with
our chip. It has two taps, a MASTER tap and a CORE tap.
The default tap is the MASTER tap, and by default the CORE tap is
disabled. There is a command to switch from the MASTER tap to the CORE
tap and vice versa. Since it is a switch, only ONE tap is connected at
a time.
We need to make openocd know that the command that switches from
MASTER to CORE disables MASTER (and the command to switch from CORE to
MASTER disables CORE).
The config file (see below) shows the hack we are currently using
(empty disable functions).
#-
#-
# Script for freescale DSP568013
#
source [find interface/signalyzer-h2.cfg]
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME dsp568013
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
# this defaults to a big endian
set _ENDIAN big
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
# force an error till we get a good number
set _CPUTAPID 0x01f2801d
}
#jtag speed
adapter_khz 10
#has only trst
reset_config trst_only
#MASTER tap
jtag newtap $_CHIPNAME chp -irlen 8 -ircapture 1 -irmask 0x03
-expected-id $_CPUTAPID
#CORE tap
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0x03 -disable
-expected-id 0x02211004
#target configuration
set _TARGETNAME $_CHIPNAME.cpu
#target create $_TARGETNAME dsp5680xx -endian $_ENDIAN -chain-position
$_TARGETNAME
#select CORE tap by modifying the TLM register.
#to be used when MASTER tap is selected.
jtag configure $_TARGETNAME -event tap-enable "
irscan $_CHIPNAME.chp 0x05;
drscan $_CHIPNAME.chp 4 0x02;
jtag tapdisable $_CHIPNAME.chp;
"
#select MASTER tap by modifying the TLM register.
#to be used when CORE tap is selected.
jtag configure $_CHIPNAME.chp -event tap-enable "
irscan $_TARGETNAME 0x4;
drscan $_TARGETNAME 4 0x1;
jtag tapdisable $_TARGETNAME;
"
jtag configure $_TARGETNAME -event tap-disable {
}
jtag configure $_CHIPNAME.chp -event tap-disable {
}
#working area at base of ram
#$_TARGETNAME configure -work-area-virt 0
#-
#-
The tap seems to switch. After switching we can get what we believe is
the CORE tap's IDCODE by executing:
> scan_chain
TapName Enabled IdCode Expected IrLen IrCap IrMask
-- --- -- -- - - --
0 dsp568013.chp Y 0x01f2801d 0x01f2801d 8 0x01 0x03
1 dsp568013.cpu n 0x 0x02211004 4 0x01 0x03
> jtag tapenable dsp568013.cpu
JTAG tap: dsp568013.chp disabled
JTAG tap: dsp568013.cpu enabled
1
> scan_chain
TapName Enabled IdCode Expected IrLen IrCap IrMask
-- --- -- -- - - --
0 dsp568013.chp n 0x01f2801d 0x01f2801d 8 0x01 0x03
1 dsp568013.cpu Y 0x 0x02211004 4 0x01 0x03
> irscan dsp568013.cpu 0x2
> drscan dsp568013.cpu 32 0
02211004
>
Switching back to the MASTER tap does not seem to work correctly.
After switching to the CORE tap and back to the MASTER tap we cannot
execute IDCODE successfully.
We get the following on telnet:
> jtag tapenable dsp568013.chp
JTAG tap: dsp568013.cpu disabled
JTAG tap: dsp568013.chp enabled
1
> irscan dsp568013.chp 0x02
> drscan dsp568013.chp 32 0
> drscan dsp568013.chp 32 0
> drscan dsp568013.chp 32 2
0004
looks like the tap is working in BYPASS. if we run "pathmove RESET"
everything works fine again:
> pathmove RESET
> irscan dsp568013.chp 0x02
> drscan dsp568013.chp 32 0
01F2801D
What is the correct way to do the switching?
Also, is there any way to get irscan to show what was shifted in?
Thanks!
--
Rodrigo.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] gdb startup from eclipse failue
>
>
> I'm running:
> Version: Helios Service Release 1
> Build id: 20100917-0705
>
> I highly suggest you update it, when I first tried the original Helios
> it was so incredibly buggy I switched back to the previous release
> until this update came out.
>
I have just updated it and re-installed cdt-master from the zip file no
change, still the problem.
> Also, are you using the GDB hardware debugging module to talk to
> openocd (part of CDT) with it? (aka not something else like older
> zylin... don't know if it's even possible with helios)
> I'm using it in standard GDB Hardware Debugging Launcher mode (down
> the bottom of the Debug Configurations window), not in DSF mode (I
> assume you'll only get this choice if you've installed DSF stuff from
> CDT as well). The verbose checkbox may have come with SR1, or with
> this mode, I'm not entirely sure. Chances are it's a SR1 thing though.
>
I am using GDB hardware dubugging and using DSF (although the problem is
with standard and DSF)
I found that the verbose checkbox is only on the standard debugger, the
output from that is:
1-gdb-set confirm off
1^done
(gdb)
2-gdb-set width 0
2^done
(gdb)
3-gdb-set height 0
3^done
(gdb)
4-interpreter-exec console echo
4^done
(gdb)
5-gdb-show prompt
5^done,value="(gdb) "
(gdb)
6-gdb-set new-console on
6^error,msg="No symbol table is loaded. Use the \"file\" command."
(gdb)
7 symbol-file C:\\eclipse\\TEST\\dbg\\Trial.elf
&"symbol-file C:eclipseTESTdbgTrial.elf\n"
symbol-file C:\\eclipse\\TEST\\dbg\\Trial.elf
8-gdb-exit
I don't know why it is complaining about the symbol file .. doesn't it use
the .elf file? Any idea's?
> > Øyvind, the command line doesn't crash so not sure what eclipse/gdb
> is
> > doing.
> > It seems my executable is the problem, because when I replace the "good"
> > project elf file with the "bad" project elf, the good project fails as
> well
> > ...
> > To duplicate the project, I just did a copy/paste within the eclipse IDE
> and
> > everything built ok really confused why this object file crashes the
> > debugger ..
>
> With copying projects, I've done this a number of times myself - often
> I forget to change the build directory in the project settings, and
> while it looks like it's compiling fine, it's actually compiling the
> old project still because it's pointing to that folder.
> These days in the Project settings -> C/C++ Build -> Builder settings
> I set the Build Directory to ${ProjDirPath} which removes this
> problem. This is for a makefile based system, which I assume you're
> using.
>
> Andrew
>
Yep, I had checked and re-checked that .. it is definetely compiling the new
code ..
Many Thanks,
Bernie
--
You always have believers and scepticts.. A True inventor is always a
believer..
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] gdb startup from eclipse failue
On Tue, Feb 15, 2011 at 7:56 AM, Bernard Mentink wrote:
> Hi Guys,
> Andrew, yes, I have checked all the settings in the Debug Configuration
> settings and they all point to the correct files, and I have the correct
> file in my load command, but gdb is crashing even before it connects to
> openocd.
> I also cannot find the "verbose console mode" checkbox in the debugger tab
> in Debug configurations dialog, do you have a different version? I am
> running eclipse version: Version: Helios Release Build id: 20100617-1415
> And openocd is Open On-Chip Debugger 0.5.0-dev version ..
I'm running:
Version: Helios Service Release 1
Build id: 20100917-0705
I highly suggest you update it, when I first tried the original Helios
it was so incredibly buggy I switched back to the previous release
until this update came out.
Also, are you using the GDB hardware debugging module to talk to
openocd (part of CDT) with it? (aka not something else like older
zylin... don't know if it's even possible with helios)
I'm using it in standard GDB Hardware Debugging Launcher mode (down
the bottom of the Debug Configurations window), not in DSF mode (I
assume you'll only get this choice if you've installed DSF stuff from
CDT as well). The verbose checkbox may have come with SR1, or with
this mode, I'm not entirely sure. Chances are it's a SR1 thing though.
> Øyvind, the command line doesn't crash so not sure what eclipse/gdb is
> doing.
> It seems my executable is the problem, because when I replace the "good"
> project elf file with the "bad" project elf, the good project fails as well
> ...
> To duplicate the project, I just did a copy/paste within the eclipse IDE and
> everything built ok really confused why this object file crashes the
> debugger ..
With copying projects, I've done this a number of times myself - often
I forget to change the build directory in the project settings, and
while it looks like it's compiling fine, it's actually compiling the
old project still because it's pointing to that folder.
These days in the Project settings -> C/C++ Build -> Builder settings
I set the Build Directory to ${ProjDirPath} which removes this
problem. This is for a makefile based system, which I assume you're
using.
Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] cortex a9
I'm having trouble getting hold of cortex a9 hardware. Anyone got anything out there to donate? The pandaboard is on order, but who knows when more will be available. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] gdb startup from eclipse failue
Hi Guys, Andrew, yes, I have checked all the settings in the Debug Configuration settings and they all point to the correct files, and I have the correct file in my load command, but gdb is crashing even before it connects to openocd. I also cannot find the "verbose console mode" checkbox in the debugger tab in Debug configurations dialog, do you have a different version? I am running eclipse version: Version: Helios Release Build id: 20100617-1415 And openocd is Open On-Chip Debugger 0.5.0-dev version .. Øyvind, the command line doesn't crash so not sure what eclipse/gdb is doing. It seems my executable is the problem, because when I replace the "good" project elf file with the "bad" project elf, the good project fails as well ... To duplicate the project, I just did a copy/paste within the eclipse IDE and everything built ok really confused why this object file crashes the debugger .. Cheers, Bernie On Mon, Feb 14, 2011 at 5:00 PM, Andrew Leech wrote: > On Mon, Feb 14, 2011 at 12:48 PM, Bernard Mentink > wrote: > > Hi All, > > I apologize for posting a somewhat openocd off-topic question, but I am > in a > > bind. > > I have been using openocd and gdb from within eclipse quite happily, > until I > > duplicated a project to start a new one, and tried debugging it. > > When gdb launches from within eclipse, I get a windoze crash dialog box, > > then the following error: > > "Error in final launch sequence > > Connection is shut down" > > However if I launch gdb from the old project it is fine. The debug > settings > > between projects are identical apart from the object code .. > > If I copy the "good" object code into the new project location ... I > still > > get the error, so doesn't look like the object code is the issue .. > > Anyone offer any suggestions? > > The only thing that comes to mind is checking to be sure that the > debug configuration settings are all referencing the new files in the > new project. On the main tab of debug configurations ensure the new > project is selected, and that the c/c++ application is set to the new > object file. Then on the startup tab that the image and symbols are > either set manually to the new one or to project binary (which has > just been checked). > > And/or, if your object file is loaded with openocd (I load mine > through gdb) check that your openocd script is pointing to the new > object/bin file. > > > I don't know how to get more info from gdb as to what is going on .. > > Depends on whether the problem is arising from gdb or openocd. openocd > script can be changed to add --debug <0-3> to its command line. > For GDP I've got a "verbose console mode" checkbox on the Debugger tab > of debug configurations (just under the popup of protocol version) > that when enabled gives a heap of extra console output. > > For reference I'm using Eclipse helios sr1 with GDB Hardware > Debugging, yagarto for gcc/gdb and git trunk openocd. > > I know what you mean about this being somewhat off topic, but I feel > your pain, there doesn't seem to be a particularly good place to > discuss issues relating to the overall open source toolchain setup. > Similarly I've got serious issues getting pipe openocd working > properly in helios. It'd be great to have running, but in the rare > configurations it actually connects to the target correctly, it debugs > (ie step, read regs, etc) at such an abysmally slow pace it's > unusable, whereas the traditional method of external tool openocd and > sockets works fine. This in on windows too, so it's quite possibly > just that pipes on windows are a bit of a hack? Either way I've given > up on pipe for now. > > Andrew > -- You always have believers and scepticts.. A True inventor is always a believer.. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] arm_adi_v5: add/move apsel member in struct adiv5_dap
This patch tries to make some order in "apsel" mess.
"dap apsel" command was quite useless (and broken) by itself.
With this patch we can use it to select between AHB or APB memory access
(previous patch 05ab8bdb813acdcd74afa71d6656c2df816cb230 was somehow broken).
- moves member apsel (in struct adiv5_dap) to ap_current
- adds apsel member
this strange choice is made trying to keep coherence in "dap apsel" command
and to keep compatibility with other code (for example cortex_a8).
Signed-off-by: Luca Ellero
---
Take this patch only as a proposal, I don't want to make changes that impact
other code without consulting the rest of developers.
If all agree, I will port the changes even in cortex_a8
Anyway, for me, this patch has a great benefit, because I'm into developing
bootloaders and with this I can dump and disassemble even ROM code.
thanks
best regards
luca
src/target/adi_v5_jtag.c |2 +-
src/target/arm_adi_v5.c | 107 +
src/target/arm_adi_v5.h | 33 --
src/target/cortex_a9.c |5 +-
4 files changed, 72 insertions(+), 75 deletions(-)
diff --git a/src/target/adi_v5_jtag.c b/src/target/adi_v5_jtag.c
index 48b4a7b..75461c3 100644
--- a/src/target/adi_v5_jtag.c
+++ b/src/target/adi_v5_jtag.c
@@ -392,7 +392,7 @@ static int jtag_ap_q_bankselect(struct adiv5_dap *dap,
unsigned reg)
return ERROR_OK;
dap->ap_bank_value = select_ap_bank;
- select_ap_bank |= dap->apsel;
+ select_ap_bank |= dap->ap_current;
return jtag_dp_q_write(dap, DP_SELECT, select_ap_bank);
}
diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index 4a3cfbb..480472f 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -100,13 +100,13 @@ static uint32_t max_tar_block_size(uint32_t
tar_autoincr_block, uint32_t address
* @param apsel Number of the AP to (implicitly) use with further
* transactions. This normally identifies a MEM-AP.
*/
-void dap_ap_select(struct adiv5_dap *dap,uint8_t apsel)
+void dap_ap_select(struct adiv5_dap *dap,uint8_t ap)
{
- uint32_t select_apsel = (apsel << 24) & 0xFF00;
+ uint32_t new_ap = (ap << 24) & 0xFF00;
- if (select_apsel != dap->apsel)
+ if (new_ap != dap->ap_current)
{
- dap->apsel = select_apsel;
+ dap->ap_current = new_ap;
/* Switching AP invalidates cached values.
* Values MUST BE UPDATED BEFORE AP ACCESS.
*/
@@ -885,73 +885,73 @@ int mem_ap_read_buf_u8(struct adiv5_dap *dap, uint8_t
*buffer,
/**/
/* Wrapping function with selection of AP*/
/**/
-int mem_ap_sel_read_u32(struct adiv5_dap *swjdp, uint8_t apsel,
+int mem_ap_sel_read_u32(struct adiv5_dap *swjdp, uint8_t ap,
uint32_t address, uint32_t *value)
{
- dap_ap_select(swjdp, apsel);
+ dap_ap_select(swjdp, ap);
return mem_ap_read_u32(swjdp, address, value);
}
-int mem_ap_sel_write_u32(struct adiv5_dap *swjdp, uint8_t apsel,
+int mem_ap_sel_write_u32(struct adiv5_dap *swjdp, uint8_t ap,
uint32_t address, uint32_t value)
{
- dap_ap_select(swjdp, apsel);
+ dap_ap_select(swjdp, ap);
return mem_ap_write_u32(swjdp, address, value);
}
-int mem_ap_sel_read_atomic_u32(struct adiv5_dap *swjdp, uint8_t apsel,
+int mem_ap_sel_read_atomic_u32(struct adiv5_dap *swjdp, uint8_t ap,
uint32_t address, uint32_t *value)
{
- dap_ap_select(swjdp, apsel);
+ dap_ap_select(swjdp, ap);
return mem_ap_read_atomic_u32(swjdp, address, value);
}
-int mem_ap_sel_write_atomic_u32(struct adiv5_dap *swjdp, uint8_t apsel,
+int mem_ap_sel_write_atomic_u32(struct adiv5_dap *swjdp, uint8_t ap,
uint32_t address, uint32_t value)
{
- dap_ap_select(swjdp, apsel);
+ dap_ap_select(swjdp, ap);
return mem_ap_write_atomic_u32(swjdp, address, value);
}
-int mem_ap_sel_read_buf_u8(struct adiv5_dap *swjdp, uint8_t apsel,
+int mem_ap_sel_read_buf_u8(struct adiv5_dap *swjdp, uint8_t ap,
uint8_t *buffer, int count, uint32_t address)
{
- dap_ap_select(swjdp, apsel);
+ dap_ap_select(swjdp, ap);
return mem_ap_read_buf_u8(swjdp, buffer, count, address);
}
-int mem_ap_sel_read_buf_u16(struct adiv5_dap *swjdp, uint8_t apsel,
+int mem_ap_sel_read_buf_u16(struct adiv5_dap *swjdp, uint8_t ap,
uint8_t *buffer, int count, uint32_t address)
{
- dap_ap_select(swjdp, apsel);
+ dap_ap_select(swjdp, ap);
return mem_ap_read_buf_u16(swjdp, buffer, count, address);
}
-int mem_ap_sel_read_buf_u32(struct adiv5_dap *swjdp, uint8_t apsel,
+int mem_ap_sel_read_buf_u32(struct adiv5_dap *swjdp, uint8_t ap,
uint8_t *buffer, int cou
Re: [Openocd-development] stm32f2xxx flash support
These changes have indeed been merged with the master branch. OpenOCD could need some good configuration scripts for these STM32 parts and eval boards... Patches gladly accepted! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] stm32f2xxx flash support
>> Everything I've tried works well... Individual sector erase, >> multiple sector erase up to the full device, image writes, image >> writes with auto-erase, gdb debugging through Eclipse. >What version of OpenOCD do you use ? I was working with Øyvind Harboe's WIP git here: http://repo.or.cz/w/openocd/oharboe.git/shortlog/refs/heads/stm32 But this looks to be the same as what he's now committed to the main git. I think there is just some extra header comments. Mike Lake ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] stm32f2xxx flash support
Everything I've tried works well... Individual sector erase, multiple sector erase up to the full device, image writes, image writes with auto-erase, gdb debugging through Eclipse. Thanks for your work on this! Mike Lake What version of OpenOCD do you use ? Regards, Laurent Gauch http://www.amontec.com Amontec JTAGkey-3 Generic USB JTAG on the road and coming with bus transport bonus as CJTAG SWD SWV I2C 1-wire ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] dsp563xx mem rw changes
No, i need to change this. Anyway the overflow of the command read buffer size in ft2232 should be fixed (patched) first. I think in some circumstances this can happen again (i have not seen this yet) and this function need some more work to avoid this case in the future. Am 14.02.2011 15:35, schrieb Øyvind Harboe: > Should this fix be merged? > > Any objections? > > Could you write a patch with a better commit comment? > > Thanks! > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] stm32f2xxx flash support
> FYI, I'm working on stm32f2xxx flash support. I've got > basic erase + programming up and running, including > block programming so performance will should be tolerable. > > Does anyone have hardware to test on out there? Hi, I have done some testing on a custom STM32F217ZGT (Rev Z) board using Olimex ARM-USB-OCD JTAG. Everything I've tried works well... Individual sector erase, multiple sector erase up to the full device, image writes, image writes with auto-erase, gdb debugging through Eclipse. Thanks for your work on this! Mike Lake ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct definition of JTAG_INSTR_CLAMP in dsp563xx_once.c
Should this patch be merged? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] dsp563xx mem rw changes
Should this fix be merged? Any objections? Could you write a patch with a better commit comment? Thanks! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232.c add functions to set high/low byte
Merged. Thanks! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/6] cortex_a9: trivial fixes
Merged. Thanks! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232.c add functions to set high/low byte
Hi Mathias,
Yes, you're right and your patch works.
We can merge it.
Also, your patch make the code source smaller. ;-)
Regards,
Laurent
http://www.amontec.com
K. wrote:
Hello,
the mpsse buffer preparation and send functionality is done in:
ft2232_set_data_bits_low_byte
ft2232_set_data_bits_high_byte
You only need to deliver the port value and direction to this functions. Thats
all.
Regards,
Mathias
Am 14.02.2011 10:36, schrieb Laurent Gauch:
Why removing a lot of code ?
As :
static int jtagkey_init(void)
{
-uint8_t buf[3];
-uint32_t bytes_written;
-
low_output= 0x08;
low_direction = 0x1b;
/* initialize low byte for jtag */
-buf[0] = 0x80; /* command "set data bits low byte" */
-buf[1] = low_output;/* value (TMS = 1,TCK = 0, TDI = 0, nOE = 0) */
-buf[2] = low_direction; /* dir (output = 1), TCK/TDI/TMS = out, TDO = in,
nOE = out */
-LOG_DEBUG("%2.2x %2.2x %2.2x", buf[0], buf[1], buf[2]);
-
-if (ft2232_write(buf, sizeof(buf), &bytes_written) != ERROR_OK)
+if (ft2232_set_data_bits_low_byte(low_output,low_direction) != ERROR_OK)
{
LOG_ERROR("couldn't initialize FT2232 with 'JTAGkey' layout");
return ERROR_JTAG_INIT_FAILED;
Please explain?
Regards,
Laurent
http://www.amontec.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232.c add functions to set high/low byte
Near as I can tell this patch just deletes lots of unecessary repetition by making a fn that should have been there in the first place, right? There is no change in behavior whatsoever, right? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232.c add functions to set high/low byte
Hello,
the mpsse buffer preparation and send functionality is done in:
ft2232_set_data_bits_low_byte
ft2232_set_data_bits_high_byte
You only need to deliver the port value and direction to this functions. Thats
all.
Regards,
Mathias
Am 14.02.2011 10:36, schrieb Laurent Gauch:
> Why removing a lot of code ?
>
> As :
>
> static int jtagkey_init(void)
> {
> -uint8_t buf[3];
> -uint32_t bytes_written;
> -
> low_output= 0x08;
> low_direction = 0x1b;
>
> /* initialize low byte for jtag */
> -buf[0] = 0x80; /* command "set data bits low byte" */
> -buf[1] = low_output;/* value (TMS = 1,TCK = 0, TDI = 0, nOE = 0) */
> -buf[2] = low_direction; /* dir (output = 1), TCK/TDI/TMS = out, TDO =
> in, nOE = out */
> -LOG_DEBUG("%2.2x %2.2x %2.2x", buf[0], buf[1], buf[2]);
> -
> -if (ft2232_write(buf, sizeof(buf), &bytes_written) != ERROR_OK)
> +if (ft2232_set_data_bits_low_byte(low_output,low_direction) != ERROR_OK)
> {
> LOG_ERROR("couldn't initialize FT2232 with 'JTAGkey' layout");
> return ERROR_JTAG_INIT_FAILED;
>
> Please explain?
>
>
> Regards,
> Laurent
>
> http://www.amontec.com
>
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232.c add functions to set high/low byte
Why removing a lot of code ?
As :
static int jtagkey_init(void)
{
- uint8_t buf[3];
- uint32_t bytes_written;
-
low_output= 0x08;
low_direction = 0x1b;
/* initialize low byte for jtag */
- buf[0] = 0x80; /* command "set data bits low byte" */
- buf[1] = low_output;/* value (TMS = 1,TCK = 0, TDI = 0, nOE = 0) */
- buf[2] = low_direction; /* dir (output = 1), TCK/TDI/TMS = out, TDO =
in, nOE = out */
- LOG_DEBUG("%2.2x %2.2x %2.2x", buf[0], buf[1], buf[2]);
-
- if (ft2232_write(buf, sizeof(buf), &bytes_written) != ERROR_OK)
+ if (ft2232_set_data_bits_low_byte(low_output,low_direction) != ERROR_OK)
{
LOG_ERROR("couldn't initialize FT2232 with 'JTAGkey' layout");
return ERROR_JTAG_INIT_FAILED;
Please explain?
Regards,
Laurent
http://www.amontec.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 6/6] cortex_a9: move dap_ap_select to arm_avi_v5
On 12/02/2011 17.22, Tomek CEDRO wrote: Hello Luca! On Sat, Feb 12, 2011 at 12:54 PM, Luca Ellero wrote: dap_ap_select was used in the code at various points, but that can lead to confusion, without any knowledge of what AP is really selected at some points. (...) This is also somehow related with the TRANSPORT and DP system that interconnects the interface/cable and the DAP (Debug Access Port). Transport is related with DAP in case of ARM because ARM DAP has SW-DP and JTAG-DP that both provide access to the AHB-AP... however in different manner - JTAG has its own registers while SWD use different "addressing" [1]. New Cortex from TI have even something that delects the DAP that makes things more complicated. I think it could be nice to clearly separate those structures (INTERFACE, TRANSPORT, PICK, DP, DAP, AP (bus), FLASH, ...) and work through their instance on the real hardware by using functions to change instance value/state. I am working on such model with (not yet functional) libswd [2] - what is more there is even a context that keeps all those instances separated, so maybe it would be possible to use many interfaces-targets at once.. work in progress... :-) Best regards, Tomek [1] http://stm32primer2swd.sf.net/ [2] http://libswd.sf.net That's good, OpenOCD for now is still very "JTAGcentric". So SW develop is always welcome. regards Luca Ellero ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
