Hi,
I'm trying to get back up to speed with OpenOCD after being away from
it for a while. I have a beagleboard and beagleboard xM that I'm
using with my flyswatter to just test out my setup (new build machine
etc.) and get familiar with the CortexA8 changes.
Anyway, I'm seeing these STICKY ERROR
Here's yet another option: (I've used this service several times - it's
just great. All details at the link.) You can also get a stencil with
your order, I think, for a few bucks more.
http://dorkbotpdx.org/wiki/pcb_order
$5.00 per square inch, Lead free, 6mil line/space rules. Ships
Internat
the srst line will be held high or low according to the interface you're using.
the ADBUS on the minimodule is like the flyswatter: X X SRST X TMS TDO
TDI TCK(AD7 to AD0)
the minimodule inits the srst line high. srst line is ADBUS5, so
that's nSRST = 0x20
if only srst is used during reset, then
This is a bit "off-topic" - but I'll offer this:
???>> to make drills metalization at home to produce advanced two
layerpcb... maybe you guys know some tricks?
??? >> I have not found a solution that works in a small-volume hobby
setting.
I really don't like messing with the Ferric Chlor
On Fri, Jul 8, 2011 at 4:30 PM, Brian Hutchinson wrote:
> But my question still remains how do I specify port "D" for IcePick?
> Pass port "4" to icepick_c_tapenable?
>
>> target/icepick.cfg from trunk that I got a few days ago has this line in it:
>>
>> drscan $jrc 32 [expr 0xa0002108 + ($port <<
On Fri, Jul 8, 2011 at 8:59 PM, Michael Schwingen
wrote:
> Note: don't put vias *in* SMD pads - they will wick away the solder when
> doing automated production.
Yup :-)
>> Still, no solution/idea on how to make pads metalization at home
>> safely... there is a clear field for a patent, hey inve
Am 07/08/2011 10:35 PM, schrieb Tomek CEDRO:
>> Simply drill the holes and solder both sides - with a thin wire if there
>> is no THT pin. This may be a bit painful, but works quite well if you
>> take care during layout so that you do not place vias under parts.
> Yes, this is the obvious solution
Hello Michael! :-)
On Fri, Jul 8, 2011 at 8:18 PM, Michael Schwingen
wrote:
> Am 07/08/2011 08:30 PM, schrieb Tomek CEDRO:
> (..) Still I don't know any sensible method
>> to make drills metalization at home to produce advanced two layer
>> pcb... maybe you guys know some tricks? :-
> Simply dril
Ahh, I hate when that happens. The only way you get the result of
0x30a0002108 is when you switch off your brain and use a calculator
and do a << 24 while in hex mode :(
Sorry. Using port '3' in my example in the OP should result in drscan
using 0xa3002108.
But my question still remains how do I
Am 07/08/2011 08:30 PM, schrieb Tomek CEDRO:
> ps/2: You can make perfect one layer pcb at home using
> photolitography (laser printer + standard laser foil + positive 20 +
> cleaner + philips halogen bulb type 14552 12V/75W only requires 1
> minute to create perfect mask). Still I don't know any s
Hi,
target/icepick.cfg from trunk that I got a few days ago has this line in it:
drscan $jrc 32 [expr 0xa0002108 + ($port << 24)] -endstate DRPAUSE
ti_beagleboard.cfg and ti_beagleboard_xm both call icepick_c_tapenable
and pass '3' as the port which I assume is IcePick "C"
So the drscan above,
On Fri, Jul 8, 2011 at 5:59 PM, Rodrigo Rosa wrote:
> i'm currently using the merge i made of the bitbang stuff with openocd.
> (..)
> nice work! :)
Thank you Rodrigo! Nice to hear you find it useful and that its
working as supposed :-) :-)
I have made some small progress on my repository and l
hi!
i'm currently using the merge i made of the bitbang stuff with openocd.
i'm using an FT2232H. one of the channels is a UART to a microproccesor.
the other channel is set to JTAG (driven by openocd) and the extra
pins on that channel (10 pins!) are being used to read status pins and
handle a po
On Fri, Jul 8, 2011 at 6:30 PM, Mahr, Stefan wrote:
How do they convert then, when they do not know from which endianes to
convert from ?
>>>
>>> Conversion is done from byte array of jtag chain.
>> How ?
>
> buf_get_u32 does conversion from uint8* array
>
> example:
> mips_ejtag_get_imp
Ah! I see.
I guess it's fine as long as OpenOCD either tristates or drive high the
reset lines when it's not doing anything.
Is that the case?
Thanks!
Matthew
On 7/8/2011 9:51 AM, Phil Fong wrote:
**
I'm
I see. Thanks for the clarifications! I understand the purposes of the
buffers much better now.
Matthew
On 7/8/2011 12:50 AM, Laurent Gauch wrote:
Hello!
I'm trying to embed a FT2232D based programmer into my board with a
STM32 (Cortex-M3 MCU).
I want the programmer to be compatible with j
>
>
>I'm trying to embed a FT2232D based programmer into my board with a STM32
>(Cortex-M3 MCU).
>
>I want the programmer to be compatible with jtagkey, so I looked at schematics
>of compaible designs.
>
>I noticed that while the JTAG signals (TCK, TDI, TDO, T
>>> How do they convert then, when they do not know from which endianes to
>>> convert from ?
>>
>> Conversion is done from byte array of jtag chain.
> How ?
buf_get_u32 does conversion from uint8* array
example:
mips_ejtag_get_impcode (mips_ejtag.c)
field.in_value is filled by jtag_add_dr_sca
On Fri, Jul 8, 2011 at 4:30 PM, Mahr, Stefan wrote:
>> How do they convert then, when they do not know from which endianes to
>> convert from ?
>
> Conversion is done from byte array of jtag chain.
How ?
> The endianness of MIPS EJTAG tap seems to have always the same endianness, no
> matter of
> How do they convert then, when they do not know from which endianes to
> convert from ?
Conversion is done from byte array of jtag chain. The endianness of MIPS EJTAG
tap seems to have always the same endianness, no matter of MIPS CPU memory
endianness.
__
On Fri, Jul 8, 2011 at 4:23 PM, Mahr, Stefan wrote:
>> Is this swap to host endianess done by buf_get_u32() in
>> mips_ejtag_drscan_32() after the queue has been executed ?
>
> Yes, buf_get_u32() and buf_set_u32() make sure uint32 is in host endianness.
OK, we are slowely nailing it... Just let m
On Fri, Jul 8, 2011 at 10:00 PM, Xiaofan Chen wrote:
> On Fri, Jul 8, 2011 at 9:21 PM, Eric Wetzel wrote:
>>
>> I downloaded the oldest version available (v4.00) from the page
>> Xiaofan provided, and downgraded the firmware. I had to reinstall my
>> libusb filter for the J-Link, but I'm not gett
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan wrote:
>> Where are those functions defined and how do they know what the target
>> endianness is?
>
> They doesn't know the target endianness, but host endianness.
How do they convert then, when they do not know from which endianes to
convert from ?
> Is this swap to host endianess done by buf_get_u32() in
> mips_ejtag_drscan_32() after the queue has been executed ?
Yes, buf_get_u32() and buf_set_u32() make sure uint32 is in host endianness.
___
Openocd-development mailing list
Openocd-development@
On Fri, Jul 8, 2011 at 4:10 PM, Mahr, Stefan wrote:
>>> - buf_set_u32 and buf_get_u32 make sure that data is in host endianness
>> Why ? Don't we want the data to be in target endianess ?
>
>>> You need swapping when reading and comparing debug registers or send code
>>> to MIPS CPU.
>> Can you g
>> - buf_set_u32 and buf_get_u32 make sure that data is in host endianness
> Why ? Don't we want the data to be in target endianess ?
>> You need swapping when reading and comparing debug registers or send code to
>> MIPS CPU.
> Can you give the example of some of these comparisons in the source
On Fri, Jul 8, 2011 at 9:21 PM, Eric Wetzel wrote:
>
> I downloaded the oldest version available (v4.00) from the page
> Xiaofan provided, and downgraded the firmware. I had to reinstall my
> libusb filter for the J-Link, but I'm not getting the same USB read
> problems. Actually, it looks like it
On Fri, Jul 8, 2011 at 3:08 PM, Andreas Fritiofson
wrote:
>
>
> On Fri, Jul 8, 2011 at 1:26 PM, Drasko DRASKOVIC
> wrote:
>>
>> On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
>> wrote:
>> > I looked briefly at the memory read functions in mips32_dmaacc.c and
>> > mips32_pracc.c and it looks
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan wrote:
>> Where are those functions defined and how do they know what the target
>> endianness is?
>
> They doesn't know the target endianness, but host endianness.
>
>
>> It sounds a little strange to do the swapping at this low level.
>
> You need sw
On Fri, Jul 8, 2011 at 1:54 PM, Mahr, Stefan wrote:
>> Problem is not in the mips32_pracc.c, thought, but when you come back
>> to mips_m4k_read_memory(), in which buf is uint8_t*.
>
> That's why the solution could be to add swapping to _mem16, _mem32 etc. and
> alway return uint8*.
I agree with
On Fri, Jul 8, 2011 at 1:38 PM, Mahr, Stefan wrote:
>> are you sure about this ?
>>
>> It seems to me that buffer[i] is directly filled by target, and I see
>> no reason that it is in the host endianess...
>
> Hi Drasko,
>
> Yes I'm sure. I tested it on my big endian host platform.
>
> I do not un
On Thu, Jul 7, 2011 at 8:27 AM, Xiaofan Chen wrote:
> On Thu, Jul 7, 2011 at 8:23 PM, Eric Wetzel wrote:
>> Alright, I uninstalled libusb-win32 0.1 and installed 1.2.4.0, and
>> installed filters for the J-Link device. Still the same result.
>>
>> I tried Freddie's binary. Still the same result.
On Fri, Jul 8, 2011 at 1:26 PM, Drasko DRASKOVIC wrote:
> On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
> wrote:
> > I looked briefly at the memory read functions in mips32_dmaacc.c and
> > mips32_pracc.c and it looks like the type usage is a bit confused. The
> > difference between the *_r
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan wrote:
> > Where are those functions defined and how do they know what the target
> endianness is?
>
> They doesn't know the target endianness, but host endianness.
>
>
You can't convert between target and host endianness if you don't know both.
I'm ge
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan wrote:
> > Where are those functions defined and how do they know what the target
> endianness is?
>
> They doesn't know the target endianness, but host endianness.
>
>
> > It sounds a little strange to do the swapping at this low level.
>
> You need sw
> Where are those functions defined and how do they know what the target
> endianness is?
They doesn't know the target endianness, but host endianness.
> It sounds a little strange to do the swapping at this low level.
You need swapping when reading and comparing debug registers or send code t
> Problem is not in the mips32_pracc.c, thought, but when you come back
> to mips_m4k_read_memory(), in which buf is uint8_t*.
That's why the solution could be to add swapping to _mem16, _mem32 etc. and
alway return uint8*.
___
Openocd-development mail
On Fri, Jul 8, 2011 at 1:38 PM, Mahr, Stefan wrote:
> > are you sure about this ?
> >
> > It seems to me that buffer[i] is directly filled by target, and I see
> > no reason that it is in the host endianess...
>
> Hi Drasko,
>
> Yes I'm sure. I tested it on my big endian host platform.
>
> I do no
> are you sure about this ?
>
> It seems to me that buffer[i] is directly filled by target, and I see
> no reason that it is in the host endianess...
Hi Drasko,
Yes I'm sure. I tested it on my big endian host platform.
I do not understand the code completely, but I think it's caused by the mips
On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
wrote:
> I looked briefly at the memory read functions in mips32_dmaacc.c and
> mips32_pracc.c and it looks like the type usage is a bit confused. The
> difference between the *_read_mem{32,16,8} functions should only be what
> kind of access is m
On Fri, Jul 8, 2011 at 1:20 PM, Andreas Fritiofson
wrote:
>
>
> On Fri, Jul 8, 2011 at 1:17 PM, Drasko DRASKOVIC
> wrote:
>>
>> I am just wandering, would :
>> t32 = *(uint32_t*)((void *)&buffer[i]);
>> quite the compiler ;)
>
> Yes probably, but it would still crash on an architecture that doesn
On Fri, Jul 8, 2011 at 1:17 PM, Drasko DRASKOVIC wrote:
> I am just wandering, would :
> t32 = *(uint32_t*)((void *)&buffer[i]);
> quite the compiler ;)
>
Yes probably, but it would still crash on an architecture that doesn't
support unaligned accesses.
/Andreas
On Fri, Jul 8, 2011 at 12:52 PM, Øyvind Harboe wrote:
> What puzzles me is that there is no warning on x86, even if I the
> -Wcast-align option
> is there
>
>
> -Wcast-align
>Warn whenever a pointer is cast such that the required alignment
> of the target is increased. For example, wa
I am just wandering, would :
t32 = *(uint32_t*)((void *)&buffer[i]);
quite the compiler ;)
BR,
Drasko
On Fri, Jul 8, 2011 at 1:14 PM, Drasko DRASKOVIC
wrote:
> On Fri, Jul 8, 2011 at 1:13 PM, Øyvind Harboe wrote:
>>> that casts void* buf to uint32_t*.
>>
>> Actually buffer is uint8_t *. The def
On Fri, Jul 8, 2011 at 1:13 PM, Øyvind Harboe wrote:
>> that casts void* buf to uint32_t*.
>
> Actually buffer is uint8_t *. The definition of target->type->read_memory is
> bad in that it uses uint8_t * instead of void *. Which is kinda the
> root of this mess.
Well, this propagate through all t
> that casts void* buf to uint32_t*.
Actually buffer is uint8_t *. The definition of target->type->read_memory is
bad in that it uses uint8_t * instead of void *. Which is kinda the
root of this mess.
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / Int
On Wed, Jul 6, 2011 at 2:42 PM, Mahr, Stefan wrote:
> "mips32_pracc_read_mem" and "mips32_pracc_write_mem" return values
> (buffer[i]) are already in host endianness, so le_to_h_u32 fails on big
> endian hosts. I already mentioned this in previous discussions.
Hi Stefan,
are you sure about this
On Fri, Jul 8, 2011 at 12:52 PM, Øyvind Harboe wrote:
> What puzzles me is that there is no warning on x86, even if I the
> -Wcast-align option
> is there
This kind of explains why I never saw it...
BR,
Drasko
___
Openocd-development mailing list
O
On Fri, Jul 8, 2011 at 12:42 PM, Øyvind Harboe wrote:
>> I still can not reproduce a problem - it buidls just fine. No warnings
>> whatsoever.
>
>
> libtool: compile: nios2-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I.
> -I/home/oyvind/workspace/zy1000/build/../openocd/src/target -I../..
> -I/home
What puzzles me is that there is no warning on x86, even if I the
-Wcast-align option
is there
-Wcast-align
Warn whenever a pointer is cast such that the required alignment
of the target is increased. For example, warn if a char * is cast to
an int * on machines where integers can onl
> I still can not reproduce a problem - it buidls just fine. No warnings
> whatsoever.
libtool: compile: nios2-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I.
-I/home/oyvind/workspace/zy1000/build/../openocd/src/target -I../..
-I/home/oyvind/workspace/zy1000/build/../openocd/src -I../../src
-DPKGDA
On Fri, Jul 8, 2011 at 12:35 PM, Øyvind Harboe wrote:
> On Fri, Jul 8, 2011 at 12:31 PM, Drasko DRASKOVIC
> wrote:
>> On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe
>> wrote:
There is no particular need to cast this into uint8_t* and this can be
kept as a void*. Would that suppress th
On Fri, Jul 8, 2011 at 12:10 PM, Øyvind Harboe wrote:
>> OK, I am starting to get this... Thanks Øyvind.
>>
>> But looking from to the code, I see no explicit casting uint8_t* to
>> uint32_t in mips_pracc code. Where did you exactly run into compiler
>> warning ?
>
> git revert 2482244b0788c007dd
On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe wrote:
>> There is no particular need to cast this into uint8_t* and this can be
>> kept as a void*. Would that suppress the warnings ?
>
> It does look like this code is using uint8_t * in lieu of void *...
Why ? It is just an address of 1-byte plac
On Fri, Jul 8, 2011 at 12:31 PM, Drasko DRASKOVIC
wrote:
> On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe
> wrote:
>>> There is no particular need to cast this into uint8_t* and this can be
>>> kept as a void*. Would that suppress the warnings ?
>>
>> It does look like this code is using uint8_t
> There is no particular need to cast this into uint8_t* and this can be
> kept as a void*. Would that suppress the warnings ?
It does look like this code is using uint8_t * in lieu of void *...
I think it would suppress the warnings, yes.
--
Øyvind Harboe - Can Zylin Consulting help on your p
On Thu, Jul 7, 2011 at 11:52 AM, Øyvind Harboe wrote:
> 011/7/7 Mahr, Stefan :
>> Øyvind Harboe wrote:
>>> It is not obvious at all from the context that there is an alignment
>>> guarantee.
>>
>> If alignment is not guaranteed, casting from uint32 to void would cause
>> problems too, wouldn't it
> OK, I am starting to get this... Thanks Øyvind.
>
> But looking from to the code, I see no explicit casting uint8_t* to
> uint32_t in mips_pracc code. Where did you exactly run into compiler
> warning ?
git revert 2482244b0788c007dd789c2
--
Øyvind Harboe - Can Zylin Consulting help on your p
On Fri, Jul 8, 2011 at 11:47 AM, Øyvind Harboe wrote:
> On Fri, Jul 8, 2011 at 11:43 AM, Drasko DRASKOVIC
> wrote:
>> On Thu, Jul 7, 2011 at 11:58 AM, Øyvind Harboe
>> wrote:
>>> Note that this problem has cropped up many places over the OpenOCD
>>> code. I'd like to get rid of it once and for
On Fri, Jul 8, 2011 at 11:43 AM, Drasko DRASKOVIC
wrote:
> On Thu, Jul 7, 2011 at 11:58 AM, Øyvind Harboe
> wrote:
>> Note that this problem has cropped up many places over the OpenOCD
>> code. I'd like to get rid of it once and for all
>>
>> I absolutely intend to fix it for MIPS, but I'd l
On Thu, Jul 7, 2011 at 11:58 AM, Øyvind Harboe wrote:
> Note that this problem has cropped up many places over the OpenOCD
> code. I'd like to get rid of it once and for all
>
> I absolutely intend to fix it for MIPS, but I'd like a good long term
> solution.
>
> With jtag queue callbacks, a
I'll be out of the office end of July. This is roughly when the
release will be cut anyway, so no changes is probably good :-)
--
Ø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/
__
Hello!
I'm trying to embed a FT2232D based programmer into my board with a
STM32 (Cortex-M3 MCU).
I want the programmer to be compatible with jtagkey, so I looked at
schematics of compaible designs.
I noticed that while the JTAG signals (TCK, TDI, TDO, TMS) are only
buffered when translati
63 matches
Mail list logo
