Hi all,
I have super-simple openocd.cfg :
--
source [find ../tcl/interface/jtagkey2.cfg]
# Processor : ARM946e (wb) rev 0 (v4l)
jtag_rclk 300
jtag_khz 0
scan_chain
--
I.e. I just want to scan my chain in order to take configure
parameters. After that I want to make target for one
On Tue, Aug 24, 2010 at 11:00 PM, David Brownell wrote:
> jtag_examine_chain_display()
>> 74376: JTAG
>> tap: mico_2.cpu tap/device found: 0x01273043 (mfg: 0x021,
>> part:
>> 0x1273, ver: 0x0)
>> Info : 218 293 core.c:949 jtag_examine_chain_display()
>> 74032: JTAG
>> tap: mico_3.cpu tap/device fo
On Wed, Aug 25, 2010 at 8:38 AM, Laurent Gauch
wrote:
>>
>> Hello David,
>> I am not so sure about this. Still smells like reset problem to me.
>>
>> It should be noted that when I let small bootloader execute from the
>> SPI flash and do the reset (and some other config), I can attach with
>> Op
On Wed, Aug 25, 2010 at 11:19 AM, Drasko DRASKOVIC
wrote:
> On Wed, Aug 25, 2010 at 8:38 AM, Laurent Gauch
> wrote:
>>>
>>> Hello David,
>>> I am not so sure about this. Still smells like reset problem to me.
>>>
>>> It should be noted that w
On Wed, Aug 25, 2010 at 5:17 PM, Drasko DRASKOVIC
wrote:
> On Wed, Aug 25, 2010 at 11:19 AM, Drasko DRASKOVIC
> wrote:
>> On Wed, Aug 25, 2010 at 8:38 AM, Laurent Gauch
>> wrote:
>>>>
>>>> Hello David,
>>>> I am not so sure about this. Stil
On Wed, Aug 25, 2010 at 5:17 PM, Drasko DRASKOVIC
wrote:
> On Wed, Aug 25, 2010 at 11:19 AM, Drasko DRASKOVIC
> wrote:
>> On Wed, Aug 25, 2010 at 8:38 AM, Laurent Gauch
>> wrote:
>>>>
>>>> Hello David,
>>>> I am not so sure about this. Stil
Hi all,
I have a following problem debugging with GDB (v. 7.1) connected via OpenOCD :
If I set hardware break point on a function everything works fine,
program stops, and I can single-step...
But if I set software breakpoint, prokram keeps stopping on this
breakpoint. I can not single step nor co
On Wed, Sep 8, 2010 at 4:50 PM, Drasko DRASKOVIC
wrote:
> Hi all,
> I have a following problem debugging with GDB (v. 7.1) connected via OpenOCD :
> If I set hardware break point on a function everything works fine,
> program stops, and I can single-step...
> But if I set soft
On Wed, Sep 8, 2010 at 8:11 PM, Øyvind Harboe wrote:
> Look into the code in arm920t. It handles caches and breakpoints...
Why arm920t, when I defined my target :
target create $_TARGETNAME arm966e -endian big -chain-position my.cpu
-variant arm946e
Should not it be in src/target/arm966e.c ?
BR
On Wed, Sep 8, 2010 at 8:43 PM, Øyvind Harboe wrote:
> On Wed, Sep 8, 2010 at 8:34 PM, Drasko DRASKOVIC
> wrote:
>> On Wed, Sep 8, 2010 at 8:11 PM, Øyvind Harboe
>> wrote:
>>> Look into the code in arm920t. It handles caches and breakpoints...
>>
>>
On Wed, Sep 8, 2010 at 9:13 PM, Øyvind Harboe wrote:
>> Øyvind,
>> if I understood you correctly, currently we do not have support for
>> arm966 for SW breakpoints (i.e. we will run into problem of repetitive
>> breakpoint hit as I mentioned), i.e. this support can be added and
>> should be simila
On Wed, Sep 8, 2010 at 9:40 PM, Øyvind Harboe wrote:
>> I still have one confusion, though. I can understand that breakpoint
>> rests in cache and that it can not be deleted and will be hit upon
>> next passage. But why it prevents me stepping on ? Any "n", "s" or "c"
>> ends in hitting the same b
On Thu, Sep 9, 2010 at 11:40 AM, Øyvind Harboe wrote:
>> Do you have some other ideas based on these new facts ?
>
> Best suggestion I have is to roll up your sleeves, break out
> the low level reference on your ARM core and start reading
Yeap, seems like there is no easy way out. Might be th
On Thu, Sep 9, 2010 at 1:07 PM, Øyvind Harboe wrote:
> On Thu, Sep 9, 2010 at 12:05 PM, Drasko DRASKOVIC
> wrote:
>> On Thu, Sep 9, 2010 at 11:40 AM, Øyvind Harboe
>> wrote:
>>>> Do you have some other ideas based on these new facts ?
>>>
>>> B
On Thu, Sep 9, 2010 at 10:53 PM, Michael Schwingen
wrote:
> Drasko DRASKOVIC wrote:
>> For the quick and dirty solution, I created int
>> arm946e_write_memory(struct target *target, uint32_t address, uint32_t
>> size, uint32_t count, uint8_t *buffer) to r
Hi all,
based on previous problem description, with software breakpoint being
constantly hit and not allowing single stepping. Memory has been
changed and replaced back with correct instruction (breakpoint does
not exist in memory anymore, this can be see by memory dump). Caches
were flashed by com
On Fri, Sep 10, 2010 at 11:42 AM, Øyvind Harboe wrote:
> Not all ARM's can flush cache via CP15. You may have to first
> write to the cache, then to physical memory, finally invalidate
> via CP15.
>
> Check out one of the other arm9 variants. It's what it had do to.
This seems to be true only for
Hi all,
I tried several methods to install OpenOCD on Windows - all without success.
First I tried explanation given here :
http://forum.sparkfun.com/viewtopic.php?t=11221
I was capable to install OpenOCD v.0.4.0, but only after moving
ftd3xx.lib to i386/libftd.a. But with this installation my Am
On Mon, Sep 13, 2010 at 5:48 PM, Freddie Chopin wrote:
> On 2010-09-13 16:18, Drasko DRASKOVIC wrote:
>>
>> I tried several methods to install OpenOCD on Windows - all without
>> success.
>
> You should have tried just one - the prebuilt binaries
On Mon, Sep 13, 2010 at 6:09 PM, Drasko DRASKOVIC
wrote:
> On Mon, Sep 13, 2010 at 5:48 PM, Freddie Chopin wrote:
>> On 2010-09-13 16:18, Drasko DRASKOVIC wrote:
>>>
>>> I tried several methods to install OpenOCD on Windows - all without
>>> success.
>&g
On Mon, Sep 13, 2010 at 6:21 PM, Freddie Chopin wrote:
> On 2010-09-13 18:16, Drasko DRASKOVIC wrote:
>>
>> I did not install libusb-win32, though. I thought that it is included
>> in the binary... Does it has to be installed separatly (manually) ? Do
>> we need F
On Mon, Sep 13, 2010 at 4:38 PM, Laurent Gauch
wrote:
> The Amontec JTAGkey-2 High-Speed USB JTAG Cable is based FTDI FT2232H and
> need newer drivers.
>
> Download our new Amontec JTAGkey Driver from :
> http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip
>
> Go to device ma
On Mon, Sep 13, 2010 at 6:58 PM, Freddie Chopin wrote:
> On 2010-09-13 18:53, Drasko DRASKOVIC wrote:
>>
>> However, can you please point me to the drivers (inf files) if they
>> are already present in OpenOCD tree, so that I do not have to use
>> http://sourceforge
On Mon, Sep 13, 2010 at 7:07 PM, Freddie Chopin wrote:
> On 2010-09-13 19:00, Drasko DRASKOVIC wrote:
>>>
>>> ...\OpenOCD\0.4.0\drivers\libusb-win32_ft2232_driver-100223.zip
>>
>> It does not exist here :
>>
>> http://openocd.git.sourceforge.n
On Tue, Sep 14, 2010 at 10:24 PM, Nived wrote:
> Hi,
> i am using openocd 0.4.0 to debug an intelmote2 device. I am able to set a
> break point and then transfer control to that point. When i do a continue
> (c) or a next (n) the execution returns to the same point.
> Is there any particular reaso
On Tue, Sep 14, 2010 at 11:42 PM, Nived wrote:
> Hi,
> I was just about to try the patch in sparkfun.
Try it, maybe it will work for you. And might throw some light on the issue.
> Btw, in one of the mails in
> the thread you mention that you used set $pc = $pc + 4 and it worked. Where
> did you
On Wed, Sep 15, 2010 at 12:22 AM, Nived wrote:
> Hi,
> I have been using software breakpoints to debug, i was using an older
> version of OpenOCD and only recently upgraded to a higher version. I can
> confirm that the issue exists for software breakpoints, how do i check the
> hardware breakpoint
On Wed, Sep 15, 2010 at 1:42 AM, Xiaofan Chen wrote:
> On Tue, Sep 14, 2010 at 12:57 AM, Drasko DRASKOVIC
> wrote:
>> On Mon, Sep 13, 2010 at 4:38 PM, Laurent Gauch
>> wrote:
>>> Download our new Amontec JTAGkey Driver from :
>>> http://www.amontec.com/
Hi Mike,
On Wed, Sep 15, 2010 at 5:23 PM, Mike Dunn wrote:
> This is odd. I am using OpenOCD on a pxa270 target and I don't see this,
> neither through telnet nor gdb. Assumed this was a cache-related problem on
> arm946.
Might be... But I introduced cache-flushing on memory write in OPenOCD
co
On Wed, Sep 15, 2010 at 7:58 PM, Mike Dunn wrote:
> On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote:
>
> I sent in a patch a while back to fix this very problem on the xscale; i.e.,
> software breakpoints didn't work because of cache issues. The problem was
> clear: executi
On Wed, Sep 15, 2010 at 8:28 PM, Drasko DRASKOVIC
wrote:
> On Wed, Sep 15, 2010 at 7:58 PM, Mike Dunn wrote:
>> On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote:
>>
>> I sent in a patch a while back to fix this very problem on the xscale; i.e.,
>> software breakpoints d
Hi all,
can anybody please explain me in the more details arm966e_read_cp15()
function (or arm920t_read_cp15()).
While fileds manipulation is intuitive, I do not get :
1) Why do we have to call jtag_add_dr_scan() two times, first time
with fields[1].in_value = NULL, other time set to correct var
Hi all,
As one of the cores in my SoC, besides ARM946 is Mico32
(http://www.latticesemi.com/products/intellectualproperty/ipcores/mico32/index.cfm),
I was wondering if there is somebody that already suceeded to add this
processor as a target and did some debug with it. Is it supported at
all and wh
Hi all,
there has been some time that I posted similar post, and I was
wondering if anybody has some information on the subject. I have been
trying without success to figure out this code, but without
appropriate comments it seems too complex.
Resolving this issue of reading/writing CP15 co-process
> Nice!
>
> Contact Lattice for help?
>
I can see also that Milkymist project has been working on this :
http://milkymist.org/
http://www.milkymist.org/wiki/index.php?title=JTAG
Maybe they will have some information...
___
Openocd-development mailing l
Hi Øyvind,
thanks very much for the comments. I just need some clarifications :
On Wed, Sep 22, 2010 at 12:00 PM, Øyvind Harboe wrote:
>> While fileds manipulation is intuitive, I do not get :
>>
>> 1) Why do we have to call jtag_add_dr_scan() two times, first time
>> with fields[1].in_value = N
On Wed, Sep 22, 2010 at 5:39 PM, Peter Stuge wrote:
> Drasko DRASKOVIC wrote:
>> > Contact Lattice for help?
>>
>> I can see also that Milkymist project has been working on this :
>> http://milkymist.org/
>
> I'm sure Sebastién will be happy to hel
On Wed, Sep 22, 2010 at 6:00 PM, Sébastien Bourdeauducq
wrote:
> Hi,
>
> Cool, we are precisely working on this at this very moment. I haven't
> touched OpenOCD yet but most probably Michael Walle (Cc'd) knows about
> it since he has already hacked an older version to work with Das
> Labor's soc-l
Hi all,
are there some instructions how to quickly add new architecture to
OpenOCD sources ?
I plan adding Lattice Mico32 target.
Where to start, which of existing targets to copy and start changing ?
Best regards,
Drasko
___
Openocd-development mailin
Hi all,
can somebody explain me please ft2232_debug_dump_buffer() log I got,
based on following :
Debug: 698 6975 ft2232.c:1884 ft2232_execute_scan(): DRSCAN type:2
Debug: 699 6975 commands.c:189 jtag_build_buffer(): DRSCAN num_fields: 7
Debug: 700 6975 commands.c:211 jtag_build_buffer(): fields[0
Hi all,
I have question regarding functionality of OpenOCD related to data
register of the TAP that is somewhere in the middle of the scan chain.
In the manual I can see this :
Warning: OpenOCD does not record information about data register
lengths, so it is important that you get the bit field
Hi all,
in the comment to the jtag_add_dr_scan() there is noted :
/**
* Generate a DR SCAN using the fields passed to the function.
* For connected TAPs, the function checks in_fields and uses fields
* specified there. For bypassed TAPs, the function generates a dummy
* 1-bit field. The bypa
OK,
we live in Paris and will check Berlin.
Belgrade seem to be next stop :
http://www.timesonline.co.uk/tol/travel/holiday_type/music_and_travel/article2744286.ece
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.
Hi all,
in my .cfg script I have :
$_TARGETNAME configure -event gdb-attach {
#soft_reset_halt
echo "Board halted on GDB attach."
}
And on GDB attach I have :
Board halted on GDB attach.
Board halted on GDB attach.
i.e. event gdb-attach is called two times in a row.
Why is this
On Mon, Oct 25, 2010 at 8:47 PM, Øyvind Harboe wrote:
>> I am using openocd-0.4.0.
>
> Try the HEAD of the master branch.
I can not, as I am creating patch for local use based on stable release.
___
Openocd-development mailing list
Openocd-development@l
On Tue, Oct 26, 2010 at 10:44 AM, Øyvind Harboe wrote:
> On Tue, Oct 26, 2010 at 10:34 AM, Drasko DRASKOVIC
> wrote:
>> On Mon, Oct 25, 2010 at 8:47 PM, Øyvind Harboe
>> wrote:
>>>> I am using openocd-0.4.0.
>>>
>>> Try the HEAD of the master bra
On Tue, Oct 26, 2010 at 11:02 AM, Øyvind Harboe wrote:
> On Tue, Oct 26, 2010 at 10:55 AM, Drasko DRASKOVIC
> wrote:
>> On Tue, Oct 26, 2010 at 10:44 AM, Øyvind Harboe
>> wrote:
>>> On Tue, Oct 26, 2010 at 10:34 AM, Drasko DRASKOVIC
>>> wrote:
>>
correct single-stepping
4) Corrects the bug on CP15 read and write, so CP15 values are now correctly R/W
Best regards,
Drasko DRASKOVIC
---
Output of
> git diff --cached --stat :
src/target/Makefile.am |2 +
src/target/arm946e.c | 712
Hello,
is there a way to store a value of some memory location in a variable
in Jim Tcl scrip.
I tried like this :
set UART_EN_HWRSTN 0x20004109
set UART_EN_HWRSTN_CUR [mdb $UART_EN_HWRSTN]
but it gives me just an empty string for UART_EN_HWRSTN_CUR (current
value of UART RESET register)
Many t
On Thu, Dec 2, 2010 at 1:05 PM, Drasko DRASKOVIC
wrote:
> Hello,
> is there a way to store a value of some memory location in a variable
> in Jim Tcl scrip.
>
> I tried like this :
>
> set UART_EN_HWRSTN 0x20004109
> set UART_EN_HWRSTN_CUR [mdb $UART_EN_HWRSTN]
>
>
On Fri, Dec 3, 2010 at 11:27 PM, Ian Lambert
wrote:
> Hey guys. I've been using the Openocd-0.4.0 with the Olimex ARM-USB-TINY
> Jtag on the Luminary lm3s6965 chip (Running FreeRTOS) for a while, and
> I've noticed some major problems with stepping in GDB.
>
> If it's of any help, I am using the C
On Tue, Dec 7, 2010 at 5:13 PM, Freddie Chopin wrote:
> On 2010-12-03 23:27, Ian Lambert wrote:
>>
>> Hey guys. I've been using the Openocd-0.4.0 with the Olimex ARM-USB-TINY
>> Jtag on the Luminary lm3s6965 chip (Running FreeRTOS) for a while, and
>> I've noticed some major problems with stepping
On Wed, Dec 8, 2010 at 6:00 AM, David Brownell wrote:
> you mentioned using an RTOS. Stepping on Cortex-M
> works poorly with a common OS feature: Use of the
> WFI (or WFE) instruction stops the core so that you
> can't get at it using JTAG. (It saves power, but
> in a way that complicates de
Hi all,
I have run into one interesting issue, so I was hoping that somebody
could help me understand the problem.
My SoC has JTAG with no SRST (just TRST), and system reset can be done
in two ways :
1) mechanically, by pressing the reset button
2) writing one byte to dedicated SOC_RESET register
On Sat, Dec 11, 2010 at 5:43 AM, Antonio Borneo
wrote:
> Hi Drasko,
> your system has an ARM946E. Should have "vector_catch" capability.
> Please check if command "arm9 vector_catch" shows the reset feature.
> In such case, after set it to catch reset, you can press the reset
> button to trigger O
Hi all,
I run into strange behavior with reset of my SoC.
I am using "arm9 vector_catch reset" to catch the reset event from the
button on the board, although "reset halt" gives the similar results,
where I defined reset-assert procedure to write a byte in a SOC_RESET
register.
After executing the
On Mon, Dec 13, 2010 at 12:14 PM, Drasko DRASKOVIC
wrote:
> Hi all,
> I run into strange behavior with reset of my SoC.
>
> I am using "arm9 vector_catch reset" to catch the reset event from the
> button on the board, although "reset halt" gives the similar resu
Hi all,
I have a setup on ARM946E that works well for loading and booting
uClinux, and during the boot phase I can stop and single-step kernel.
But once booted, when it gives prompt, pressing CTRL-C in GDB can not
halt the board :
^CHalt timed out, wake up GDB.
Program received signal SIGINT, In
On Mon, Dec 13, 2010 at 5:40 PM, Drasko DRASKOVIC
wrote:
> Hi all,
> I have a setup on ARM946E that works well for loading and booting
> uClinux, and during the boot phase I can stop and single-step kernel.
>
> But once booted, when it gives prompt, pressing CTRL-C in GDB can not
&
HI all,
I have a simple question for anyone worked with MIPS (EJTAG) before -
does it support "halt" mode debugging, or ROM monitor mode is only
option ?
Coming from the ARM world, I am looking for "halt" mode debugging, as
I am very limited on chip surface to add additional ROM.
1)
I read in one
Hi all,
reading more MIPS documentation I came to certain assumptions how JTAG
debugging works with these cores (EJTAG), so I'll try to answer myself
for the future reference, but also as a possible motivation for
someone to comment on these :
On Fri, Jan 7, 2011 at 4:06 PM, Drasko DRAS
Hi all,
I am using Amontec JTAG-Key 2 probe and openocd.udev rules that are in
the current git repo are not working for me once placed into
/etc/udev/rules.d, notably because these two lines :
SUBSYSTEM!="usb", GOTO="openocd_rules_end"
ENV{DEVTYPE}!="usb_device", GOTO="openocd_rules_end"
Commentin
Hi all,
I just tried to load a small test ELF like this :
80008000 <_ftext>:
80008000: 3c088001lui t0,0x8001
80008004: 8d089014lw t0,-28652(t0)
80008008: 24090005li t1,5
8000800c: 3c018001lui at,0x8001
80008010: ac2990
.
Passing -endian big when creating target, write to the SRDAM
controller register is wrong, and thus SDRAM is never well configured.
Why is this happening and what seems to be wrong ?
BR,
Drasko
On Wed, Mar 16, 2011 at 11:42 AM, Drasko DRASKOVIC
wrote:
> Hi all,
> I just tried to load a
n Wed, Mar 16, 2011 at 3:19 PM, Drasko DRASKOVIC
wrote:
> Hi all,
> this seems to be OpenOCD endianess probelem for MIPS big endian targets.
>
> This is what I concluded with further instigation. I started target in
> little endian mode and let it configure SDRAM. In this case SDRAM
couldn't read enough bytes from FT2232 device (0 < 5)
couldn't read from FT2232
register read failed
Do you have any idea why this is happening and can this be related to
Amontec JTAG Key 2 probe I have been using ?
Best regards,
Drasko
On Wed, Mar 16, 2011 at 4:37 PM, Drasko D
2232.c:1933 ft2232_execute_scan():
DRSCAN type:3
On Thu, Mar 17, 2011 at 6:57 AM, Mathias K. wrote:
> Hello,
>
> Am 16.03.2011 20:19, schrieb Drasko DRASKOVIC:
>> However, trying to load a bigger image function
>> mips_m4k_bulk_write_memory() is called an
Hi all,
I have few questions regarding MIPS and endianess :
1) In openocd/src/target/mips_m4k.c we can see that target endianess
is checked and treated only mips_m4k_bulk_write_memory() in and not
mips_m4k_write_memory() and mips_m4k_read_memory(). Why is this so ?
(It leads to wrong SDRAM setup,
e:
> Hello,
>
> the send buffer looks okay. Maybe this is a timeout problem. Do you use the
> d2xx or ftdi library?
>
>
> Regards,
>
> Mathias
>
>
> Am 17.03.2011 13:14, schrieb Drasko DRASKOVIC:
>> 3174056 Debug: 3174389 188209 ft2232.c:809 ft2232_sen
On Thu, Mar 17, 2011 at 2:50 PM, Laurent Gauch
wrote:
> Hi Mathias K.,
>
> You have this command buffer
>
> 4b 02 01 39 02 00 00 c0 04 3b 06 80 6b 01 81 4b 02 03
>
> 4b 02 01 / TMS shift no read
> 39 02 00 00 c0 04 / IN OUT 3 bytes read
> 3b 06 80 / IN OUT 1 byte read
> 6b 01 81 / TMS shift 1 byte
, Mathias K. wrote:
> I think you should reduce your clock speed first.
>
> Am 17.03.2011 16:27, schrieb Drasko DRASKOVIC:
>> clock speed 6000 kHz
>
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
htt
On Thu, Mar 17, 2011 at 4:53 PM, Laurent Gauch
wrote:
> I am waiting on the log using the Amontec JTAGkey d2xx WHQL certified driver
> . Maybe we will see something different, in this case it is a trouble in
> the libftdi . If the same some trouble in the higher JTAG level in openocd
> source.
I
On Thu, Mar 17, 2011 at 10:19 PM, David Claffey wrote:
> Hi Drasko,
>
> I proposed a solution for the MIPS big-endian problem in the past. See
> https://lists.berlios.de/pipermail/openocd-development/2009-June/008659.html
>
> The FASTDATA patch was accepted later and included the
> mips_m4k_bulk_w
Hi Øyvind,
OK, thanks. It is still early to post the patch, but once I have
working and tested version I will post it in a separate thread, as you
suggested.
Best regards,
Drasko
On Fri, Mar 18, 2011 at 7:02 AM, Øyvind Harboe wrote:
> Hi,
>
> thanks for working on this!
>
> Could you post this
t; Compile with d2xx support
>
> Regards,
> Laurent Gauch
> http://www.amontec.com Amontec JTAGkey-3 coming soon ! Generic USB JTAG
> CJTAG SWD SWO serial wire debug interface 1.5V 1.8V 2.5V 3.3V 5V auto-sense
> protected IOs With RTCK support
> maximum 30Mhz JTAG TCK frequeny
>
&
run_command() 35784: Command failed with
error code -100
BR,
Drasko
On Fri, Mar 18, 2011 at 11:45 AM, Drasko DRASKOVIC
wrote:
> Hello Laurent,
> I have trouble compiling your driver in static (I copied libe from
> build/i386 to stati_lib):
> checking whether standard driver
I have :
1) Amotnec JTAGkey-2
and
2) Amontec JTAGkey Tiny
BR,
Drasko
On Fri, Mar 18, 2011 at 12:14 PM, Laurent Gauch
wrote:
> Drasko DRASKOVIC wrote:
>>
>> Hello Laurent,
>> I have trouble compiling your driver in static (I copied libe from
>> build/i386 to stat
Hi Andy,
are you using big or little endian CPU ?
Is mips32_pracc_fastdata_xfer() function called, and does it succeeds,
or it falls back to simple mips_m4k_write_memory() ?
BR,
Drasko
On Tue, Mar 22, 2011 at 2:20 PM, Andrew Lyon wrote:
> Hi,
>
> I am using a ft2232 based jtag device with a mip
ct it - is it well loaded in memory ?
If this does not work, you can forget any debugging...
Best regards,
Drasko
On Thu, Mar 24, 2011 at 11:43 AM, Andrew Lyon wrote:
> On Wed, Mar 23, 2011 at 2:06 PM, Drasko DRASKOVIC
> wrote:
>> Hi Andy,
>> are you using big or little endi
where indeed potential problems with FTDI 2232are mentioned, but I do
not get it well. I hope that it will make more sense for Laurent or
some other expert in this field.
Best regards,
Drasko
On Fri, Mar 18, 2011 at 12:17 PM, Drasko DRASKOVIC
wrote:
> I have :
>
> 1) Amotnec JTAGke
On Fri, Mar 25, 2011 at 11:01 AM, Spencer Oliver wrote:
> I am not really following the big endian issues, however i can confirm that
> mips32_pracc_fastdata_xfer is working for pic32 - which is little endian.
Hi Spen,
I am suspicious about this. Take these lines of code for example :
/
On Fri, Mar 25, 2011 at 11:55 AM, Andrew Lyon wrote:
> Drasko,
>
> I read somewhere that some bigendian mips systems still have little
> endian tap
This is true. I am not MIPS expert, I am going through EJTAG manual
right now to find confirmations...
> , perhaps that explains why on my system dat
dongle I am using, but there
is small chance.
Which dongle are you using ?
Best regards,
Drasko
On Fri, Mar 25, 2011 at 11:52 AM, Andrew Lyon wrote:
> On Thu, Mar 24, 2011 at 11:01 AM, Drasko DRASKOVIC
> wrote:
>> Hi Andy,
>> I am very surprised that OpenOCD works for big end
On Fri, Mar 25, 2011 at 1:02 PM, Andrew Lyon wrote:
> On Fri, Mar 25, 2011 at 11:40 AM, Drasko DRASKOVIC
> wrote:
>> Hi Andy,
>> thank you for these tests, it is very helpful. The problem you have
>> can be easily solved by applying David Claffey's patches
On Fri, Mar 25, 2011 at 1:41 PM, Laurent Gauch
wrote:
> I did not reproduce your trouble, but we already see "couldn't read enough
> bytes from FT2232 device ", when we started with the JTAGkey-2 (FT2232H),
> but is was coming from a too old driver, bugged with the FT2232H part.
> But this should
On Fri, Mar 25, 2011 at 4:29 PM, Spencer Oliver wrote:
> On 25/03/2011 10:37, Drasko DRASKOVIC wrote:
>>
>> Obviausly, there is an inconsistency of mips_ejtag_fastdata_scan() in
>> the loop comparing to previous references - it is not preceded by
>> mips_ejtag_set_i
Hi all,
I downloaded D2XX driver from here :
http://www.ftdichip.com/Drivers/D2XX.htm. It is version 1.0.4 for
Linux x86 (32-bit).
I tried compiling OpenOCD with libftd2xx statically (which is by
default). Configuration is failing with :
checking uninstalled ftd2xx distribution...
-L/home/ddrasko
FT2232 device (0 < 5)
problem that I saw before with libftdi.
However, more surprising are build problems with OpenOCD and D2XX
1.0.4 that I described below.
BR,
Drasko
On Mon, Mar 28, 2011 at 4:07 PM, Drasko DRASKOVIC
wrote:
> Hi all,
> I downloaded D2XX driver from here :
> http:/
> hardware. If you work with
> linux you can try "dmesg" to get some reports about hardware problems,
> specially usb.
>
>
> Regards,
>
> Mathias
>
> Am 29.03.2011 12:37, schrieb Drasko DRASKOVIC:
>> Hi all,
>> commenting out FT_GetLa
Hi all,
I am confused by this very strange loop in mips32_pracc.c :
static int wait_for_pracc_rw(struct mips_ejtag *ejtag_info, uint32_t *ctrl)
{
uint32_t ejtag_ctrl;
while (1)
{
mips_ejtag_set_instr(ejtag_info, EJTAG_INST_CONTROL);
ejtag_ct
On Tue, Mar 29, 2011 at 2:19 PM, Xiaofan Chen wrote:
> Just wondering why you prefer to use d2xx under Linux. I remember
> the tests done in the past shows that it does not have real advantages
> over libftdi or libftdi-1.0. Under Windows, yes. But under Linux, seems no.
I do not. Actually, I hat
On Fri, Mar 25, 2011 at 4:29 PM, Spencer Oliver wrote:
> On 25/03/2011 10:37, Drasko DRASKOVIC wrote:
>>
>> Obviausly, there is an inconsistency of mips_ejtag_fastdata_scan() in
>> the loop comparing to previous references - it is not preceded by
>> mips_ejtag_set_i
On Tue, Mar 29, 2011 at 1:30 PM, Spencer Oliver wrote:
> On 29/03/2011 12:09, Drasko DRASKOVIC wrote:
>>
>> What does the while(1) serves for here - we will always do just one
>> pass. In my opinion this is wrong and confusing.
>>
>
> You are right - i would guess
Hi all,
how to use static version of libftdi, libftdi.a, during OpenOCD build.
Are there some switches to pass to configure like --with-ftd2xx-lib=static ?
Configure is constantly failing trying to go for shared version by default :
./conftest: error while loading shared libraries: libftdi.so.1:
On Mon, Mar 28, 2011 at 10:07 PM, Drasko DRASKOVIC
> wrote:
>> Hi all,
>> I downloaded D2XX driver from here :
>> http://www.ftdichip.com/Drivers/D2XX.htm. It is version 1.0.4 for
>> Linux x86 (32-bit).
>>
>> I tried compiling OpenOCD with libftd2xx statically
On Tue, Mar 29, 2011 at 3:16 PM, Xiaofan Chen wrote:
> On Tue, Mar 29, 2011 at 9:07 PM, Drasko DRASKOVIC
> wrote:
>> Hi all,
>> how to use static version of libftdi, libftdi.a, during OpenOCD build.
>>
>> Are there some switches to pass to configure
On Tue, Mar 29, 2011 at 3:28 PM, Xiaofan Chen wrote:
> On Tue, Mar 29, 2011 at 8:24 PM, Drasko DRASKOVIC
> wrote:
>> On Tue, Mar 29, 2011 at 2:19 PM, Xiaofan Chen wrote:
>>> Just wondering why you prefer to use d2xx under Linux. I remember
>>> the tests done in t
On Tue, Mar 29, 2011 at 3:40 PM, Xiaofan Chen wrote:
> On Tue, Mar 29, 2011 at 9:34 PM, Drasko DRASKOVIC
> wrote:
>> I obderved this erroor :
>> Error: couldn't read enough bytes from FT2232 device (0 < 5)
>> recently, and only on my 14Kc MIPS based FPGA.
>&g
On Tue, Mar 29, 2011 at 4:03 PM, Mathias K. wrote:
> Linux: d2xx 0.4.16-r1
Yes, it works for me also with 0.4.16. Problem is in new D2XX 1.0.4.
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.d
ong).
BTW. Andy, what core are you using ? M4K or something else ? I am
using M14Kc, but I believe that EJTAG implementation should be exactly
the same...
Best regards,
Drasko
On Tue, Mar 29, 2011 at 2:35 PM, Drasko DRASKOVIC
wrote:
> On Fri, Mar 25, 2011 at 4:29 PM, Spencer Oliver wrote:
>
1 - 100 of 276 matches
Mail list logo
