I have try the master branch, and found that the reason is tck frequence.
Both 0.4.0 and master branch, if I set "jtag_khz 500", "resume 0x0c40"
will be timeout sometime. If I did not set the jtag speed(use default as 6MHz),
there was not "timeout".
But, if use tck as 6MHz, the ope
On Thu, Nov 11, 2010 at 2:44 AM, Peter Stuge wrote:
>
> Andrew Leech wrote:
> > Now I need to figure out how to bypass the lpc via software rather
> > than physically changing the chain. I can't seem to find much
> > information about how bypass works with openocd, do you have any
> > idea?
>
> So
Hi,
in attachment the driver for the serial NOR flash controller of ST
SPEAr devices.
The first patch adds driver support and documentation, the second one
adds the proper lines in the (current) only board file of this device
family.
The driver structure follows the prototype of the other drivers
On 2010-11-12 00:26, Peter Stuge wrote:
Freddie Chopin wrote:
according to OpenOCD (brilliant) policy of target config files
I think it would be great if you stopped complaining using sarcasm
and instead help analyze and improve. I think you have a lot of
experience that is valuable.
The "pol
On 2010-11-12 00:05, Peter Stuge wrote:
My perception of the situation is strongly the opposite. There is no
policy, relax, there is just people working together making something
generic that works. This is a difficult task.
I cannot agree, as there were many discussions about whether
reset_co
Freddie Chopin wrote:
> according to OpenOCD (brilliant) policy of target config files
I think it would be great if you stopped complaining using sarcasm
and instead help analyze and improve. I think you have a lot of
experience that is valuable.
The "policy" stuff is nonsense. If there is a comp
Freddie Chopin wrote:
>>> How common is what? Lack of SRST?
>>
>> Yes?
>
> For me such situations are almost impossible,
Impossible? Weird measure of common. :)
> but some strange and bizarre policy makes default target file for
> stm32 tell OpenOCD there is no reset at all...
My perception of
Hi!
I've thought about that whole patch which adds "cortex-m3 reset_config"
command and I think it's not very good now (if I correctly understand
its behavior).
Let's say, that there is a chip which has some problems with
SYSRESETREQ, so the target config file forces VECTRESET (which is not
Øyvind Harboe wrote:
> By default OpenOCD should build the Jim Tcl submodule
> automatically, but there should be an option to use the
> installed Jim Tcl.
I disagree strongly with this.
Moving Jim out into a separate package means that it should also be
treated as a separate package. (Which it i
On 2010-11-11 20:47, Spencer Oliver wrote:
I disagree with this patch as SYSTEMRESET is not supported as expected
on all cores.
Shouldn't the code assume that this standard mechanism works as the
standard says? If some chip does not support it, than this chip should
have VECTRESET selected in
On 2010-11-11 19:34, Peter Stuge wrote:
Freddie Chopin wrote:
If no SRST pin is available, Cortex-M3 soft-reset is required,
How common is this case?
How common is what? Lack of SRST?
Yes?
For me such situations are almost impossible, but some strange and
bizarre policy makes default ta
On 11/11/2010 11:00, Freddie Chopin wrote:
Hi!
This patch changes the default behaviour of Cortex-M3 soft-reset. More
details can be found in thread "STM32 reset_config".
I've tested that with STM32 - everything works fine, peripherals are
reset as they should be (with standard cfg files).
4\/
On 11/11/2010 05:01, Peter Stuge wrote:
Spencer Oliver wrote:
The default behaviour was changed to make it compatible with all
cortex-m3 cores - will have to check but some stm32 and nxp parts
had issues using SYSTEMRESET.
Please give more detail about those nxp parts?
All LPC17xx devices
On Thu, Nov 11, 2010 at 6:52 PM, David Brownell wrote:
>
>
> --- On Thu, 11/11/10, Øyvind Harboe wrote:
>
>> What output do you get when running bootstrap?
>
> This time I noticed some stuff ... but that seems
> wrong. Bootstrap should bootstrap, not leave the
> job incomplete and in need of rep
Freddie Chopin wrote:
>>> If no SRST pin is available, Cortex-M3 soft-reset is required,
>>
>> How common is this case?
>
> How common is what? Lack of SRST?
Yes?
>>> so use SYSRESETREQ by default.
>>
>> Default instead of SRST, or default instead of VECTRESET?
>
> Instead of VECTRESET,
Ok.
>
--- On Thu, 11/11/10, Øyvind Harboe wrote:
> What output do you get when running bootstrap?
This time I noticed some stuff ... but that seems
wrong. Bootstrap should bootstrap, not leave the
job incomplete and in need of repairs.
>
> It should print the instructions on how to build and ins
What output do you get when running bootstrap?
It should print the instructions on how to build and install
jim tcl.
Did you try running the current master branch?
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://w
On 2010-11-11 17:51, Peter Stuge wrote:
Freddie Chopin wrote:
If no SRST pin is available, Cortex-M3 soft-reset is required,
How common is this case?
How common is what? Lack of SRST?
so use SYSRESETREQ by default.
Default instead of SRST, or default instead of VECTRESET?
Instead of VE
After bootstrap and configure (per instructions), I get
build failures on Linux with an
all but pure clone of mainline. (Quilt and git report only
a patch to the git ignore file, not to any code.)
Same config I've used on this machine most of the last year.
make all-recursive
make[1]: Enteri
Freddie Chopin wrote:
> If no SRST pin is available, Cortex-M3 soft-reset is required,
How common is this case?
> so use SYSRESETREQ by default.
Default instead of SRST, or default instead of VECTRESET?
//Peter
___
Openocd-development mailing list
--- On Thu, 11/11/10, Andreas Fritiofson wrote:
> It's not an assumption, it's in the manual. Do you have an example of
> a microcontroller which doesn't reset the bulk of the peripherals on a NRST
> or equivalent?
Not handy, no; it surprised me too. ISTR there
was a register controlling th
On Thu, Nov 11, 2010 at 08:48, Øyvind Harboe wrote:
> Try:
>
> openocd -c "interface dummy" -c "gdb_memory_map disable" -f target/stm32.cfg
>
No segfault in this case.
--
Domen
___
Openocd-development mailing list
Openocd-development@lists.berlios
Please try the master branch.
0.4.0 is a bit old for reporting bugs to the list.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
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
The log is:
> load_image init/init.bin 0x0c00
776 bytes written at address 0x0c00
downloaded 776 bytes in 0.046875s (16.167 kb/s)
> resume 0x0c00
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x21d3 pc: 0x0cd8
> resum
HI,
I want to debug u-boot for s3c6410 with openocd 0.4.0, but I fount that the
resume command "timeout" some time.
So I use a simple program to test, it runs on the internal sram .
I use openocd to download init.bin to the internal sram , and use the
resume command to run it.
The steps
Hi!
This patch changes the default behaviour of Cortex-M3 soft-reset. More
details can be found in thread "STM32 reset_config".
I've tested that with STM32 - everything works fine, peripherals are
reset as they should be (with standard cfg files).
4\/3!!
From c8303d849cea9a2ebf0f2e36f1bec8f
On Wed, Nov 10, 2010 at 11:10 PM, David Brownell wrote:
>
>> >>> Today I've noticed that resetting the chip
>> with OpenOCD does NOT reset
>> >>> peripheals (the chip is STM32F103RBT8), which
>> IMO is not very good...
>
> Not all SoCs reset peripherals like that; don't
> assume they do. Likewise
27 matches
Mail list logo
