Re: [Openocd-development] [PATCH] mips target

[Drasko DRASKOVIC]

On Wed, May 25, 2011 at 4:28 PM, Mahr, Stefan  wrote:
> Hi,
>
> attached patch fixes the endianess so mips/ejtag can be used on a big endian 
> host.
>
>
> Btw.: There is still an endianness issue with mips target. Drasko adds 
> endianness swapping (that I removed two years ago)

Why did you remove it ?

> to mips_m4k.c (commit b1256894598296b54a1827e7ac797ad1c60a0b18). But some 
> swapping is already done in target.c, e.g. for target_get_buffer_u32. While 
> "dump_image" works fine, "mdw" does not. > To my mind whole endianness 
> swapping should be done in target.c, not in mips_m4k.

I put it where it was before, but I agree that we should do the swap
in target.c.

 > What do you think?

I'll have to test this, and I'll not have MIPS board before beginning
of next week. Otherwise I can not tell if it's correct. From my
memory, I'd say that mdw worked correctly for me...

Best regards,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] mips target

[Øyvind Harboe]

Looking at this patch, it's clearly wrong to cast a pointer to a host 32 bit
integer to a pointer to a sequence of bytes to shift out.

I don't know about the rest of the issues offhand, but I see Drask was
going to have a look at it.




-- 
Ø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/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] mips target

[Mahr, Stefan]

>> Btw.: There is still an endianness issue with mips target. Drasko adds 
>> endianness swapping (that I removed two years ago)
> Why did you remove it ?

I removed swapping in mips_m4k, because for commands like mdw the swapping was 
already done in target.c. If a target was selected as big endian, swapping was 
done twice. So setting endianness had no effect. I did not realized that 
dump_image works different.

Since you revert this change, same issue again :)

BR,
Stefan

-Ursprüngliche Nachricht-
Von: Drasko DRASKOVIC [mailto:drasko.drasko...@gmail.com] 
Gesendet: Donnerstag, 26. Mai 2011 12:12
An: Mahr, Stefan
Cc: openocd-development@lists.berlios.de
Betreff: Re: [PATCH] mips target

On Wed, May 25, 2011 at 4:28 PM, Mahr, Stefan  wrote:
> Hi,
>
> attached patch fixes the endianess so mips/ejtag can be used on a big endian 
> host.
>
>
> Btw.: There is still an endianness issue with mips target. Drasko adds 
> endianness swapping (that I removed two years ago)

Why did you remove it ?

> to mips_m4k.c (commit b1256894598296b54a1827e7ac797ad1c60a0b18). But some 
> swapping is already done in target.c, e.g. for target_get_buffer_u32. While 
> "dump_image" works fine, "mdw" does not. > To my mind whole endianness 
> swapping should be done in target.c, not in mips_m4k.

I put it where it was before, but I agree that we should do the swap
in target.c.

 > What do you think?

I'll have to test this, and I'll not have MIPS board before beginning
of next week. Otherwise I can not tell if it's correct. From my
memory, I'd say that mdw worked correctly for me...

Best regards,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] mips target

[Øyvind Harboe]

This patch fixes an obvious bug.

Unless I hear objections, I will merge.

That said, there may be other code that is building upon this broken behavior
that needs to get fixed afterwards.

If I see fixes for those followup bugs in short order, I'd be inclined to wait
until we have a sequence of patches that straightens this out.

-- 
Ø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/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD for STM32F2xx microcontroller

[Fleurette , Bruno]

Hi Sylvain,

I have exactly the same eval board and also the same OpenOCD issue when trying 
to write the binary on the STM32F2 flash:

device id = 0x20006411
Cannot identify target as a STM32 family.

Did you succeed in updating OpenOCD sources?
BR,

Bruno

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD for STM32F2xx microcontroller

[Øyvind Harboe]

There is more than one stm32 flash driver, use the "other one"



-- 
Ø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/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD for STM32F2xx microcontroller

[Fleurette , Bruno]

Øyvind Harboe  writes:

> 
> There is more than one stm32 flash driver, use the "other one"
> 


Sorry but I only know stm32x... could you pls give a name to the "other one"?

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD for STM32F2xx microcontroller

[Øyvind Harboe]

> Sorry but I only know stm32x... could you pls give a name to the "other one"?

cd src
find . | grep stm32



-- 
Ø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/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Provisional eCos RTOS support

[Alan Bowman]

> Could you provide a list of what order you give GDB/OpenOCD commands and
> which GDB-Remote commands/responses you see?

I'm remote from my test hardware at the moment - I'll try to do that
as soon as possible

> The way I did it in the RTOS’s was that if the current thread was set to 0
> or 1 then it returned the current running context (i.e. the true register
> values). This seems to avoid the problem you’re having.

I had noticed that, and queried whether the test should be 1 or -1 (I
thought it should be -1, and submitted a patch to change it).  I have
a thread whose ID is 1, and the wrong thing was happening.  My code
seems to correctly differentiate between current/stacked threads, and
return the correct register values for them.

> · You may need to fix the GDB bug described in
> http://sourceware.org/bugzilla/show_bug.cgi?id=12648

I don't think I'm running afoul of that, since you mention Eclipse and
I'm using command-line GDB.  It could be a problem, though, and I'll
look into it.

> · Generally you will want to make your OpenOCD script blank the
> device memory so that the RTOS awareness does not read old, invalid thread
> information

I think the issue I saw was that gdb requested the current thread (qC)
before the RTOS thread update was called.  Because I had no explicit
clear of the RTOS structure after reset (irrespective of the state of
my target's RAM) the current thread that was returned was the same as
the last update prior to target reset.

Thanks for the feedback

Alan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] ft2232 - how to read/write from/to gpio

[Rodrigo Rosa]

> Ah, I forgot to mention the most important - to be able to realize
> transport I have extended "struct jtag_interface" with "transfer_bits"
> and "signal_operate" methods that transfer bitstream out/in of the
> char array and can switch/read specified signal (exactly what you
> need). "queue_execute" was not enough to make transport work without
> rewriting/touching existing code, as all of the functions were already
> implemented for jtag, so these functions were necessary to be added,
> maintains backward compatibility and does not breaks existing code,
> allowing to create bitstreams and signaling for transports other than
> jtag. Old drivers will simply have null pointer to these functions, so
> it will be easy to recognize if function is implemented.
>
> signal_operate() can read and write i/o states based on signal name
> string (char array). struct jtag_interface was also extended with
> *signals field, where signals is the singly linked list of structures,
> where each element holds the name string, bitmask, value and pointer
> to next element. Interface driver can register signals during
> interface initialization, so signals can be easily used for
> signal_operate(). It is possible ofcourse to implement tcl command to
> work with this function directly with the driver code :-) Signals are
> dynamic list because each signal in fact is a port mask that can
> contain more than one pin/signal, to allow more versatility, also it
> can be device specific and further extending static structures (ie.
> layout) caused more troubles than good.
>
> I will send the patches with SWD update next week, but still I have
> problems to make things work as expected - ie. right now, at
> initialization, I get "bug error" that target is out of bouns, while I
> do not initialize any target ;-)
>
> Best regards,
> Tomek
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

hey great!!
i look forward to your patch :)

-- 
Rodrigo.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Compilation errors

[Freddie Chopin]

Hi!

I'm trying to compile new OpenOCD source (from git) in my 
crosscompilation setup but I see these errors:



/../../src/rtos/'`rtos.c
libtool: compile:  i686-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. 
-I../../../src/rtos -I../.. -I../../../src -I../../src 
-DPKGDATADIR=\"/usr/local/share/openocd\" -I../../../jimtcl -I../../jimtcl 
-Wno-sign-compare -g -O2 -D__USE_MINGW_ANSI_STDIO -Wall -Wstrict-prototypes 
-Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align 
-Wredundant-decls -Werror -MT librtos_la-rtos.lo -MD -MP -MF .deps/librtos_la-rtos.Tpo -c 
../../../src/rtos/rtos.c -o librtos_la-rtos.o
cc1: warnings being treated as errors
../../../src/rtos/rtos.c: In function ‘gdb_thread_packet’:
../../../src/rtos/rtos.c:147: error: unknown conversion type character ‘l’ in 
format
../../../src/rtos/rtos.c:147: error: too many arguments for format
../../../src/rtos/rtos.c:223: error: unknown conversion type character ‘l’ in 
format
../../../src/rtos/rtos.c:223: error: too many arguments for format
../../../src/rtos/rtos.c:320: error: unknown conversion type character ‘l’ in 
format
../../../src/rtos/rtos.c:320: error: format ‘%s’ expects type ‘char *’, but 
argument 3 has type ‘int64_t *’
../../../src/rtos/rtos.c:320: error: too many arguments for format
../../../src/rtos/rtos.c:473: error: unknown conversion type character ‘l’ in 
format
../../../src/rtos/rtos.c:473: error: too many arguments for format
../../../src/rtos/rtos.c:497: error: unknown conversion type character ‘l’ in 
format
../../../src/rtos/rtos.c:497: error: too many arguments for format


Any hints for solving that? Should I try to use a different setup for 
compiling OpenOCD for Windows (both 32- and 64-bit) - if yes, what do 
you use? Currently I use i686-w64-mingw32 and x86_64-w64-mingw32 - is 
there a better option using up-to-date compilers? I had to comment out 
"dlerror" definition in jim-win32compat.h but that was simple to fix. 
The sscanf()s that cause errors look pretty wild...


Thx for help!

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] stm32f2xxx flash support

[Orbital_sFear]

simon qian  writes:

> 
> 
> It's fast for 27kBytes/s for flash + erase. STM32F200 has 16M internal RC, so
> the JTAG can run at 2.5M.
> 
> As I test for STM32F100, flash programming is usually at 13KBytes/s under
> OpenOCD.
> 
> 
> ST website is not available in China, I don't know the state of STM32F200.
> I have placed an sample order of 20 STM32F205 1M/64Pin, and they only give
> the price, but not sure about when I can get it.
> 
> The PCB will be sent to factory next week.2011/2/3 Øyvind Harboe
> 
> On Wed, Feb 2, 2011 at 7:53 PM, simon qian
>  wrote:
> 
> > I have one STM32F207, but PCB will be available at end of this month.
> > I'll go to ST this month for some STM32F205s if available.
> > I can do the test if I can get the samples, but only for SWD, because there
> > is only SWD available in my PCB.
> That's great!
> In my first tests I'm seeing 27kBytes/s for flash + erase. 128kBytes
> sectors takes
> as much as 1000ms to erase(per the datasheet).
> I was able to clean up the branch, but I want to let it cool off
> before I merge it.
> --
> 
> Øyvind Harboe
> Can Zylin Consulting help on your project?
> US toll free 1-866-980-3434 / International +47 51 87 40
> 27http://www.zylin.com/zy1000.html
> ARM7 ARM9 ARM11 XScale Cortex
> JTAG debugger and flash programmer
> 
> 
> 
> 
> -- Best Regards, SimonQianhttp://www.SimonQian.com
> 
> 
> 
> ___
> Openocd-development mailing list
> Openocd-development@...
> https://lists.berlios.de/mailman/listinfo/openocd-development
> 


The driver works great.  Here is my experience with it.  I went to openocd,
Downloaded the get repo, built.  The first time I flashed code, everything
worked great.  The second time, I ran into issues.

When I was trying to flash, I got the follow:
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x40023c08
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x40023c08

Finally I got a fix.  First, ensure the blocks aren't write protected

Inside gdb, run this: monitor mdw 0x40023c14 should yield 0x0fffaaec
If you don't get 0x0fff, do the following:
reboot the board
monitor mww 0x40023c08 0x08192A3B
monitor mww 0x40023c08 0x4C5D6E7F
monitor mww 0x40023c14 0x0fffaaec
reboot the board
monitor mdw 0x40023c14 should yield 0x0fffaaec

Second, here is my program script, the key is that you must clear any error 
bits at 0x40023c0c:

  #Get the system ready to run these commands
init

  #flash a program
halt
sleep 10

  #Clear any flash errors   REQUIRED!
sleep 10
mww 0x40023c0c 0xf3

  #Flash my code
sleep 10
flash probe 0
flash write_bank 0 /tmp/target.bin 0

  # get thsi thing started again
reset init
reset run
shutdown

Great job on the stm32F207 driver, thanks!
-Orbital_sFear

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] stm32f2xxx flash support

[Orbital_sFear]

The driver works great.  Here is my experience with it.  I went to openocd, 
Downloaded the get repo, built.  The first time I flashed code, everything 
Worked great.  The second time, I ran into issues.

When I was trying to flash, I got the follow:
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x40023c08
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x40023c08

Finally I got a fix.  First, ensure the blocks aren't write protected

Inside gdb, run this: monitor mdw 0x40023c14 should yield 0x0fffaaec
If you don't get 0x0fff, do the following:
reboot the board
monitor mww 0x40023c08 0x08192A3B
monitor mww 0x40023c08 0x4C5D6E7F
monitor mww 0x40023c14 0x0fffaaec
reboot the board
monitor mdw 0x40023c14 should yield 0x0fffaaec

Second, here is my program script, the key is that you must clear any error 
bits at 0x40023c0c:

  #Get the system ready to run these commands
init

  #flash a program
halt
sleep 10

  #Clear any flash errors   REQUIRED!
sleep 10
mww 0x40023c0c 0xf3

  #Flash my code
sleep 10
flash probe 0
flash write_bank 0 /tmp/target.bin 0

  # get thsi thing started again
reset init
reset run
shutdown

Great job on the stm32F207 driver, thanks!
-Orbital_sFear

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Error: .. adapter speed not selected

[Paul Claessen]

In April (2011) I built openocd version 0.5.0-dev-00858 and used it 
successfully with an Olimex OpenOCD JTAG Tiny.
I recently built version 0.5.0-dev-00882 and I now get the following error:

Error: An adapter speed is not selected in the init script. Insert a call to 
adapter_khz or jtag_rclk to proceed.in procedure 'init'

(This was also reported for a J-Link build, but it seems to be a more generic 
issue: see:
https://lists.berlios.de/pipermail/openocd-development/2011-May/018922.html )

An answer was given that stated 
“You have to specify the JTAG communication frequency, there no longer is any 
concept of a "default" frequency.”

(See: 
https://lists.berlios.de/pipermail/openocd-development/2011-May/018923.html )

I would argue that if you remove a concept of default values and thereby BREAK 
working systems and turn them form working systems into failing systems, then, 
IMHO, no matter how elegant and architecturally correct your ‘concept removal’ 
was, you violated the extremely important idea of backward compatibility and 
you have, for all practical purposes, introduced a bug.

We’re now having a system, that used to work fine, that no longer works and 
gives me (just a simple user) some very vague hint about adding a call somehow 
somewhere without further details as to parameters etc.
I hope someone can reverse all this.

In the mean time, can someone provide me with some more detailed instructions 
on where and how exactly to add this call?


Kind regards,

~ Paul Claessen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Error: .. adapter speed not selected

[Michael Schwingen]

Am 05/26/2011 09:12 PM, schrieb Paul Claessen:
> In April (2011) I built openocd version 0.5.0-dev-00858 and used it
> successfully with an Olimex OpenOCD JTAG Tiny.
> I recently built version 0.5.0-dev-00882 and I now get the following
> error:
>  
> Error: An adapter speed is not selected in the init script. Insert a
> call to adapter_khz or jtag_rclk to proceed.in procedure 'init'

> I would argue that if you remove a concept of default values and
> thereby BREAK working systems and turn them form working systems into
> failing systems, then, IMHO, no matter how elegant and architecturally
> correct your 'concept removal' was, you violated the extremely
> important idea of backward compatibility and you have, for all
> practical purposes, introduced a bug.
>  
> We're now having a system, that used to work fine, that no longer
> works and gives me (just a simple user) some very vague hint about
> adding a call somehow somewhere without further details as to
> parameters etc.
> I hope someone can reverse all this.
>  
> In the mean time, can someone provide me with some more detailed
> instructions on where and how exactly to add this call?
The adapter_khz and jtag_rclk commands are described in chapter 8.4 of
the manual (openocd.pdf).

If you are using one of the config files provided with OpenOCD, then
these need to be fixed - however, you don't tell which config file and
which target you are using, so I can only guess.

If you use your own config file, you have to expect some breakage both
on development versions and new major releases. Backward compatibility
is a nice goal, but it can hamper progress and produce layers of cruft
in the code, so there are situations where it is best to enforce some
change and keep the code clean.

cu
Michael

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Error: .. adapter speed not selected

[Paul Claessen]

From: Michael Schwingen 
Sent: Thursday, May 26, 2011 3:26 PM
To: Paul Claessen 
Cc: openocd-development@lists.berlios.de 
Subject: Re: [Openocd-development] Error: .. adapter speed not selected
Am 05/26/2011 09:12 PM, schrieb Paul Claessen: 
  In April (2011) I built openocd version 0.5.0-dev-00858 and used it 
successfully with an Olimex OpenOCD JTAG Tiny. 
  I recently built version 0.5.0-dev-00882 and I now get the following error: 

  Error: An adapter speed is not selected in the init script. Insert a call to 
adapter_khz or jtag_rclk to proceed.in procedure 'init' 



  I would argue that if you remove a concept of default values and thereby 
BREAK working systems and turn them form working systems into failing systems, 
then, IMHO, no matter how elegant and architecturally correct your ‘concept 
removal’ was, you violated the extremely important idea of backward 
compatibility and you have, for all practical purposes, introduced a bug. 

  We’re now having a system, that used to work fine, that no longer works and 
gives me (just a simple user) some very vague hint about adding a call somehow 
somewhere without further details as to parameters etc. 
  I hope someone can reverse all this. 

  In the mean time, can someone provide me with some more detailed instructions 
on where and how exactly to add this call? 
The adapter_khz and jtag_rclk commands are described in chapter 8.4 of the 
manual (openocd.pdf).

If you are using one of the config files provided with OpenOCD, then these need 
to be fixed - however, you don't tell which config file and which target you 
are using, so I can only guess.

If you use your own config file, you have to expect some breakage both on 
development versions and new major releases. Backward compatibility is a nice 
goal, but it can hamper progress and produce layers of cruft in the code, so 
there are situations where it is best to enforce some change and keep the code 
clean.

cu
Michael




Michael,

Thanks for your much appreciated quick response.
I’m using my own .cfg for file an Olimex Tiny. I simply added the suggested 
‘adapter_khz’ (with value 1000, although I’m not sure what a reasonable value 
would be; I guess that depends on the target) and everything now works as 
before.
I guess I was a bit thrown off by mentioning of adding function calls to init 
routines and someone even mentioned mods to core.c.

As for cleaning stuff up and keeping code tidy, I certainly can see your point 
there, but I still think ‘breaking’ things should only be allowed in extreme 
situations, IMHO, and then only with very clear instructions on how to adapt to 
the new situation.
In this case, a system that didn’t work for all cases (but did for most), was 
replaced with one that didn’t work for ANY. That’s hardly progress. Besides, 
the concept of (a documented!) default value that works in many, but not all, 
cases seems like a very valid thing to have, to me.
Also, the one making this change must have realized that without also fixing 
all the now broken sample scripts/cfg files, the implemented solution wasn’t 
complete and would trip up quite a few people. I realize that fixing cfg files 
isn’t very sexy, but still ...
I also realize that it seems a bit ungrateful to bitch about work that’s done 
by volunteers, for free. Let me assure everyone that I only mention this in an 
effort to help create a better product, and I hope to one day contribute some 
of my own resources.
Despite the bitching, I truly DO thoroughly appreciated everyone’s efforts put 
into this cool tool!

Kind regards,

~ Paul

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Provisional eCos RTOS support

[Alan Bowman]

Evan

> Could you provide a list of what order you give GDB/OpenOCD commands and
> which GDB-Remote commands/responses you see?

I have attached two files.  gdb_trace.txt shows two runs through the
same sequence of events:
- attach to the remote target
- reset the target
- set breakpoint
- run to breakpoint
- "info threads"
- single step

The first time through, the thread information looks correct, as far
as I can tell.  However, single stepping causes the error message.  I
immediately reconnect to OpenOCD and perform the exact same steps, and
I don't get an error message.  The output from OpenOCD is also
attached.  Notice on the first connection (line 35) we return QC0 for
current thread, and on the second connection (line 168) we return
QC0005.  The data in the last response is incorrect, since the
RTOS code hasn't even queried the target at that point.  Still, it
seems to make a difference of some kind...

GDB is version 7.2, modified as you described in your bug report -
this has made no noticeable difference in this case.  OpenOCD is
top-of-trunk, except that I have edited the functions you suggested to
print the GDB messages going in and out.

I hope you can see something I've missed

Alan
alan@shiny:~/eval_board$ ~/software/gdb_build/bin/arm-eabi-gdb 
install/tests/kernel/current/tests/thread2 
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-eabi".
For bug reporting instructions, please see:
...
Reading symbols from 
/home/alan/eval_board/install/tests/kernel/current/tests/thread2...done.
(gdb) target remote silver.config:
Remote debugging using silver.config:
hal_reset_vsr () at 
/home/alan/ecos-tools/ecos_hg/packages/hal/cortexm/arch/current/src/hal_misc.c:124
124 {
(gdb) mon reset halt
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, 
ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x06430041 (mfg: 0x020, part: 0x6430, ver: 
0x0)
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x0100 pc: 0x08001764 msp: 0x2001
(gdb) br thread2.cxx:148
Breakpoint 1 at 0x80001d6: file 
/home/alan/ecos-tools/ecos_hg/packages/kernel/current/tests/thread2.cxx, line 
148.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, entry2 (data=2) at 
/home/alan/ecos-tools/ecos_hg/packages/kernel/current/tests/thread2.cxx:148
148 s0.post();
(gdb) info threads
[New Thread 1]
[New Thread 2]
[New Thread 3]
[New Thread 4]
  5 Thread 4 (No Name :  : Sleeping)  Cyg_Scheduler::unlock_inner (new_lock=1) 
at /home/alan/ecos-tools/ecos_hg/packages/kernel/current/src/sched/sched.cxx:223
  4 Thread 3 (No Name :  : Sleeping)  Cyg_Scheduler::unlock_inner (new_lock=1) 
at /home/alan/ecos-tools/ecos_hg/packages/kernel/current/src/sched/sched.cxx:223
  3 Thread 2 (main :  : Ready)  Cyg_HardwareThread::thread_entry 
(thread=0x20006074) at 
/home/alan/ecos-tools/ecos_hg/packages/kernel/current/src/common/thread.cxx:84
  2 Thread 1 (Idle Thread :  : Ready)  Cyg_HardwareThread::thread_entry 
(thread=0x20003f24) at 
/home/alan/ecos-tools/ecos_hg/packages/kernel/current/src/common/thread.cxx:84
* 1 Thread 5 (No Name :  : Ready)  entry2 (data=2) at 
/home/alan/ecos-tools/ecos_hg/packages/kernel/current/tests/thread2.cxx:148
(gdb) n
thread.c:598: internal-error: is_thread_state: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
thread.c:598: internal-error: is_thread_state: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
alan@shiny:~/eval_board$ ~/software/gdb_build/bin/arm-eabi-gdb 
install/tests/kernel/current/tests/thread2 
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-eabi".
For bug reporting instructions, please see:
...
Reading symbols from 
/home/alan/eval_board/install/tests/kernel/current/tests/thread2...done.
(gdb) target remote silver.config:
Remote debugging using silver.config:
hal_reset_vsr () at 
/home/alan/ecos-tools/ecos_hg/packages/hal/cortexm/arch/current/src/hal_misc.c:124
124 {
(gdb) mon reset halt
JTAG tap: stm32.cpu tap/

Re: [Openocd-development] Error: .. adapter speed not selected

[Michael Schwingen]

Am 05/26/2011 10:47 PM, schrieb Paul Claessen:
>
> Thanks for your much appreciated quick response.
> I'm using my own .cfg for file an Olimex Tiny. I simply added the
> suggested 'adapter_khz' (with value 1000, although I'm not sure what a
> reasonable value would be; I guess that depends on the target) and
> everything now works as before.
> I guess I was a bit thrown off by mentioning of adding function calls
> to init routines and someone even mentioned mods to core.c.
>  
> As for cleaning stuff up and keeping code tidy, I certainly can see
> your point there, but I still think 'breaking' things should only be
> allowed in extreme situations, IMHO, and then only with very clear
> instructions on how to adapt to the new situation.
> In this case, a system that didn't work for all cases (but did for
> most), was replaced with one that didn't work for ANY. That's hardly
> progress. Besides, the concept of (a documented!) default value that
> works in many, but not all, cases seems like a very valid thing to
> have, to me.
The problem is that the default value would have to be ridiculous low -
IIRC, for a synthesized core running at 32kHz, it would have to be 4kHz
or lower, so most users would *have* to edit their configs anyway to put
in a value that works for their board.

Otherwise, you get strange results, including "works part of the time"
or "works partially". A clear error message is the much better solution
IMHO.

> Also, the one making this change must have realized that without also
> fixing all the now broken sample scripts/cfg files, the implemented
> solution wasn't complete and would trip up quite a few people. I
> realize that fixing cfg files isn't very sexy, but still
The change happened not long time ago - the master branch is work in
progress. I agree this definitely has to be cleaned up before the next
release.

> I also realize that it seems a bit ungrateful to bitch about work
> that's done by volunteers, for free. Let me assure everyone that I
> only mention this in an effort to help create a better product, and I
> hope to one day contribute some of my own resources.
> Despite the bitching, I truly DO thoroughly appreciated everyone's
> efforts put into this cool tool!
>
That's fine. Every bit helps - if you supply a patch that improves one
ore more of the supplied sample scripts, or even the documentation, that
will help improve OpenOCD without digging into the code.

cu
Michael



___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Verify checksum command patch and FT2232 channels patch

[Øyvind Harboe]

Hi Evan,

w.r.t. the checksum command, I'm thinking it would be better to
implement it as a tcl command so i can be used in Tcl code:

if {![verify_image_checksum]} {#do some stuff here}

You'll probably need to post the ft2232 patch in a separate subject to get
some reaction.


-- 
Ø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/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development