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
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/
On Fri, Jul 8, 2011 at 11:43 AM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
On Thu, Jul 7, 2011 at 11:58 AM, Øyvind Harboe oyvind.har...@zylin.com
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
On Fri, Jul 8, 2011 at 11:47 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
On Fri, Jul 8, 2011 at 11:43 AM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
On Thu, Jul 7, 2011 at 11:58 AM, Øyvind Harboe oyvind.har...@zylin.com
wrote:
Note that this problem has cropped up many places
On Thu, Jul 7, 2011 at 11:52 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
011/7/7 Mahr, Stefan stefan.m...@sphairon.com:
Ø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
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
On Fri, Jul 8, 2011 at 12:31 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe oyvind.har...@zylin.com
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
On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe oyvind.har...@zylin.com 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
On Fri, Jul 8, 2011 at 12:10 PM, Øyvind Harboe oyvind.har...@zylin.com 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
On Fri, Jul 8, 2011 at 12:35 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
On Fri, Jul 8, 2011 at 12:31 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe oyvind.har...@zylin.com
wrote:
There is no particular need to cast this into
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
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
On Fri, Jul 8, 2011 at 12:42 PM, Øyvind Harboe oyvind.har...@zylin.com 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
On Fri, Jul 8, 2011 at 12:52 PM, Øyvind Harboe oyvind.har...@zylin.com 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
___
On Wed, Jul 6, 2011 at 2:42 PM, Mahr, Stefan stefan.m...@sphairon.com 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
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 /
On Fri, Jul 8, 2011 at 1:13 PM, Øyvind Harboe oyvind.har...@zylin.com 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
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
drasko.drasko...@gmail.com wrote:
On Fri, Jul 8, 2011 at 1:13 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
that casts void* buf to
On Fri, Jul 8, 2011 at 12:52 PM, Øyvind Harboe oyvind.har...@zylin.comwrote:
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.
On Fri, Jul 8, 2011 at 1:17 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com
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 1:20 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
On Fri, Jul 8, 2011 at 1:17 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
I am just wandering, would :
t32 = *(uint32_t*)((void *)buffer[i]);
quite the compiler ;)
Yes probably, but it would
On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com 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
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:38 PM, Mahr, Stefan stefan.m...@sphairon.comwrote:
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
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
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 to
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan stefan.m...@sphairon.comwrote:
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.
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan stefan.m...@sphairon.comwrote:
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
On Fri, Jul 8, 2011 at 1:26 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com
wrote:
On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com 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
On Thu, Jul 7, 2011 at 8:27 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Thu, Jul 7, 2011 at 8:23 PM, Eric Wetzel thewet...@gmail.com 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
On Fri, Jul 8, 2011 at 1:38 PM, Mahr, Stefan stefan.m...@sphairon.com 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.
On Fri, Jul 8, 2011 at 1:54 PM, Mahr, Stefan stefan.m...@sphairon.com 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
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan stefan.m...@sphairon.com 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.
On Fri, Jul 8, 2011 at 3:08 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
On Fri, Jul 8, 2011 at 1:26 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
I looked briefly at the memory
On Fri, Jul 8, 2011 at 9:21 PM, Eric Wetzel thewet...@gmail.com 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,
- 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
code ?
On Fri, Jul 8, 2011 at 4:10 PM, Mahr, Stefan stefan.m...@sphairon.com 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.
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
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan stefan.m...@sphairon.com 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
On Fri, Jul 8, 2011 at 10:00 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Jul 8, 2011 at 9:21 PM, Eric Wetzel thewet...@gmail.com 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
On Fri, Jul 8, 2011 at 4:23 PM, Mahr, Stefan stefan.m...@sphairon.com 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
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:30 PM, Mahr, Stefan stefan.m...@sphairon.com 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
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_scan with 4
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
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
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
On Fri, Jul 8, 2011 at 6:30 PM, Mahr, Stefan stefan.m...@sphairon.com 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:
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
On Fri, Jul 8, 2011 at 5:59 PM, Rodrigo Rosa rodrigorosa...@gmail.com 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
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,
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
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
Hello Michael! :-)
On Fri, Jul 8, 2011 at 8:18 PM, Michael Schwingen
rincew...@discworld.dascon.de 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
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 for
On Fri, Jul 8, 2011 at 8:59 PM, Michael Schwingen
rincew...@discworld.dascon.de 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
On Fri, Jul 8, 2011 at 4:30 PM, Brian Hutchinson b.hutch...@gmail.com 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 +
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 Chloride
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,
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
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
61 matches
Mail list logo
