On Tue, Aug 3, 2010 at 1:17 AM, Alain Mouette wrote:
>
> Em 02-08-2010 18:58, Øyvind Harboe escreveu:
>>
>> On Mon, Aug 2, 2010 at 11:36 PM, Alain Mouette wrote:
>>>
>>> Could anyone give (or point to) an example of a flash for Cortex-M3 that
>>> first chenges the internal cpu clock to 50MHz, the
Mike Dunn wrote:
> > This is a standard FT2232 device. More info at their web page:
> > http://shop.ngxtechnologies.com/product_info.php?cPath=26&products_id=30
>
> Hopefully this is not OT or inappropriate... anyone care to comment on
> this product? Done business with them? It's competitively
On 07/31/2010 06:26 PM, Peter Stuge wrote:
> This is a standard FT2232 device. More info at their web page:
> http://shop.ngxtechnologies.com/product_info.php?cPath=26&products_id=30
>
Hopefully this is not OT or inappropriate... anyone care to comment on
this product? Done business with them?
Em 02-08-2010 18:58, Øyvind Harboe escreveu:
On Mon, Aug 2, 2010 at 11:36 PM, Alain Mouette wrote:
Could anyone give (or point to) an example of a flash for Cortex-M3 that
first chenges the internal cpu clock to 50MHz, then changes OpenOCD clock to
12MHz and only then writes the flash?
This
On Mon, Aug 2, 2010 at 11:36 PM, Alain Mouette wrote:
> Could anyone give (or point to) an example of a flash for Cortex-M3 that
> first chenges the internal cpu clock to 50MHz, then changes OpenOCD clock to
> 12MHz and only then writes the flash?
This depends *entirely* on the part and periphera
Could anyone give (or point to) an example of a flash for Cortex-M3 that
first chenges the internal cpu clock to 50MHz, then changes OpenOCD
clock to 12MHz and only then writes the flash?
I get confused with the sequence of commands (not the cpu specifics
to change the clock/pll)
Thanks,
--- On Mon, 8/2/10, Øyvind Harboe wrote:
> From: Øyvind Harboe
> Subject: Re: [Openocd-development] lpc1768 low clock rate
> To: "David Brownell"
> Cc: "Freddie Chopin" ,
> openocd-development@lists.berlios.de
> Date: Monday, August 2, 2010, 2:09 PM
> On Mon, Aug 2, 2010 at 11:01 PM,
> David
On Mon, Aug 2, 2010 at 11:30 PM, Freddie Chopin wrote:
> On 2010-08-02 23:09, Øyvind Harboe wrote:
>>
>> I also need to know what jtag clock it is safe to run reset-init at
>
> Instead of dividing by 6, try dividing by 8 - 500kHz.
I have to go as low as 300kHz before "reset run" works reasona
On 2010-08-02 23:09, Øyvind Harboe wrote:
I also need to know what jtag clock it is safe to run reset-init at
Instead of dividing by 6, try dividing by 8 - 500kHz.
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
h
Merged.
Thanks!
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@list
On Mon, Aug 2, 2010 at 11:01 PM, David Brownell wrote:
>> But why as low as 100kHz?
>
> Because no reset-init method is kicking
> in the xtal oscillator and PLL, so the chip
> is clocked almost as slow as it'll go.
OK. So 100kHz maximum JTAG khz is not a pathological sign?
> You want faster? Wr
> But why as low as 100kHz?
Because no reset-init method is kicking
in the xtal oscillator and PLL, so the chip
is clocked almost as slow as it'll go.
You want faster? Write a real reset-init
method that clocks the chip faster ... at least
until app code kicks in and overrides.
- Dave
__
On Mon, Aug 2, 2010 at 10:52 PM, Freddie Chopin wrote:
> On 2010-08-02 22:34, Øyvind Harboe wrote:
>>
>> Does anyone have any idea why the lpc1768 requires
>> such a low clock rate?
>>
>> "reset run" seems to require as low as 100kHz Could this
>> be due to the app I'm running is messing with
On 2010-08-02 22:34, Øyvind Harboe wrote:
Does anyone have any idea why the lpc1768 requires
such a low clock rate?
"reset run" seems to require as low as 100kHz Could this
be due to the app I'm running is messing with the clock?
Thoughts?
Doesn't LPC17xx (as well as LPC23xx, LPC24xx, ...
On Mon, Aug 2, 2010 at 10:43 PM, David Brownell wrote:
>> Does anyone have any idea why the
>> lpc1768 requires
>> such a low clock rate?
>>
>> "reset run" seems to require as low as 100kHz Could
>> this
>> be due to the app I'm running is messing with the clock?
>
> Probably. The chip can ru
> Does anyone have any idea why the
> lpc1768 requires
> such a low clock rate?
>
> "reset run" seems to require as low as 100kHz Could
> this
> be due to the app I'm running is messing with the clock?
Probably. The chip can run at 100 MHz ISTR,
but if it's running at a slower rate, JTAG wil
Does anyone have any idea why the lpc1768 requires
such a low clock rate?
"reset run" seems to require as low as 100kHz Could this
be due to the app I'm running is messing with the clock?
Thoughts?
(This is with the KEIL lpc1768 kit + zy1000 interface)
> reset run
JTAG tap: lpc1768.cpu tap/
Hi everyone. I noticed some incorrect information in the user manual
regarding how the vector table is handled on the xscale, so for your
consideration, here's a short patch that corrects it, and adds a
little more detail I thought might be helpful.
The documentation states that OpenOCD does not
On 2010-07-31 17:49, Olof Tångrot wrote:
I just tested [1000 100, 10 ,1] kHz (under Fedora 12 running a 64-bit
Athlon X2 processor) and the result is the same...
"The Error: couldn't read enough bytes from FT2232 device (0< 81)."
Yesterday I've seen exactly the same problem on our Polish foru
Xiaofan Chen wrote:
> >> cd libftdi-1.0 && ../openocd/bootstrap && ./configure \
> >> --prefix=/tmp/test --disable-libftdipp --disable-python-binding \
> >> --without-examples && make install && cd ..
>
> I see. You are using the autoconf scripts. The libftdi-1.0 developers
> are mainly using CMak
Xiaofan Chen wrote:
> > The libusb-1.0 dir in CFLAGS is a workaround for a bug in how libftdi
> > uses libusb-1.0. libftdi should do #include but
> > does #include which is wrong. This forces all libftdi
> > users to mess with include paths, to add the directory that libftdi
> > happened to be bu
On Mon, Aug 2, 2010 at 7:34 PM, Xiaofan Chen wrote:
> On Mon, Aug 2, 2010 at 6:26 PM, Peter Stuge wrote:
>> The libusb-1.0 dir in CFLAGS is a workaround for a bug in how libftdi
>> uses libusb-1.0. libftdi should do #include but
>> does #include which is wrong. This forces all libftdi
>> users
On Mon, Aug 2, 2010 at 6:26 PM, Peter Stuge wrote:
> The libusb-1.0 dir in CFLAGS is a workaround for a bug in how libftdi
> uses libusb-1.0. libftdi should do #include but
> does #include which is wrong. This forces all libftdi
> users to mess with include paths, to add the directory that libft
Olof Tångrot wrote:
> I need a build script,
..
> I prefer to use Linux since libusb, libftdi and openocd is more
> native on that platform.
Try this..
mkdir -p /tmp/test/src || exit 1
cd /tmp/test/src
git clone git://git.libusb.org/libusb.git
git clone git://developer.intra2net.com/libftdi-1.0
g
On Mon, Aug 2, 2010 at 9:43 AM, Xiaofan Chen wrote:
> On Mon, Aug 2, 2010 at 4:17 AM, Olof Tångrot wrote:
>> It also crashes with the replacement version libftdi that is linked to
>> libusb-1.0 discussed earlier.
>
> Hmm, I will try it out myself. I am not so sure if this has something
> to do wi
Øyvind Harboe wrote:
> Does anyone know of what the right fn to call for a case insensitive
> strstr would be?
>
> Implement from scratch based on toupper?
Maybe a loop over strcasencmp()..
There's an strcasestr() extension when #define _GNU_SOURCE.
//Peter
Does anyone know of what the right fn to call for a case insensitive
strstr would be?
Implement from scratch based on toupper?
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash progr
27 matches
Mail list logo
