Øyvind Harboe wrote:
On Fri, May 15, 2009 at 10:31 PM, Michael Fischer fische...@t-online.de
wrote:
Hello List,
I have tested the speed from 1606 with the patch from
Magnus and the 1787 with a FT2232 under Windows. The
target was a STR710 with external RAM.
A very old speed table
Øyvind Harboe wrote:
Voodoo?
What's your standard deviation?
Nicolas Pitre showed it to be *huge* in his case...
Could be a red herring...
My recent testing of image_loads and image_dumps show a sd of less than
5% (not calculated :)
A larger sd. is IMHO a signal of a hidden bug
Øyvind Harboe wrote:
Well, since it is more than five days old I suppose it is dead fish.
I could have been more precise to say: it is much more work to
apply a patch later than sooner, ignoring the risk.
It's balance.
But I can tell you that all the state transition stuff works
When I do this for the Beagle i just use
# set the current target, should not be nexessary with only one target
configured
targets omap3.cpu
# call tcl functions without the extra target name
mem2array dataval 32 [expr 0x54011000 + $reg_num * 4] 1
Regards
Magnus
Strontium wrote:
Hmm,
So i
Magnus Lundin wrote:
When I do this for the Beagle i just use
# set the current target, should not be nexessary with only one target
configured
targets omap3.cpu
# call tcl functions without the extra target name
mem2array dataval 32 [expr 0x54011000 + $reg_num * 4] 1
And testing
Strontium wrote:
I haven't seen any Cortex A8 activity on the list, lately, so I wonder
if anyone has come across these issues.
See attached script:
I tried implementing the functions described in the Cortex A8 TRM. I
was trying to see if I could read CPU ARM registers.
The code seems
I am so tired of this endless need unplanned for change.
And talk of planned and stable releases.
There are so much more important things to attend to in order to make
OpenOCD truly stable and versatile.
Debugging, regression testing, finding root causes of problems before
fixing them, the list
Zach Welch wrote:
Magnus, (resent w/ Reply-All... oops)
Please let me know if there is anything that I can do to help this
situation. I am sorry that you are so frustrated right now, and I wish
there was something that I could have done to prevent it.
Z
The question is well received.
There might be some confusion about the focus on r1606
So let me clarify:
This is the revision I work from.
This where I am testing the new jtag transition table stuff, I have had
everything working and then suddenly it breaks, and I thaught everyting
was identical. It is confusing.
A lot
Øyvind Harboe wrote:
The idea behind the the u8 * and buf stuff is to handle host endianness.
the size of the integers in the array is orthogonal to solving the endianess.
I cannot really see the need. Yes it takes a little while to learn, but
any work where you stuff bits into
David Brownell wrote:
So there I am, trying to do basic PLL init code using TCL.
All I have to do is read a register, modify the result, and
write it back ... write a register ... read a register and
do something based on a bitfield ... etc. Not what I'd call
pretty TCL code (is there such
So some progress, but nothing more ;)
(all: Above error is from TCL script containing ocd_mem2array
romtable_cid 32 [expr ($debugbase0xF000) + 0xFF0] 4)
Do you have any special patches or do I need any special configure
option to enable ( compile) tclapi.c?
Standard build, nothing
Dirk Behme wrote:
Magnus Lundin wrote:
Hi
Rev 1547, Added two commands that just returns values in hex, good for
scripting.
dap baseaddr
dap apid
Next I started playing with Tcl scripts that scans the ROM table and
installed components. This is my first shot at JimTcl in OpenOCD
Øyvind Harboe wrote:
Does anyone have any objections to adding a command
to disable jtag_check_value_mask()?
This is along the lines of the existing verify_ircapture and
could speed things up.
Checking would be on by default just like verify_ircapture.
Such a command would serve two
Øyvind Harboe wrote:
On Sat, May 9, 2009 at 11:45 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
Řyvind Harboe wrote:
Does anyone have any objections to adding a command
to disable jtag_check_value_mask()?
This is along the lines of the existing verify_ircapture and
could speed
Øyvind Harboe wrote:
I've been thinking about how to make OpenOCD faster.
One challenge is that there are things that can be done
that will make OpenOCD run faster that are target
specific.
It can take quite a bit of effort from the user to read up
on all the weird and wonderful obscure
Zach Welch wrote:
On Thu, 2009-05-07 at 20:26 +0200, Øyvind Harboe wrote:
On Thu, May 7, 2009 at 7:18 PM, David Brownell davi...@pacbell.net wrote:
On Thursday 07 May 2009, Øyvind Harboe wrote:
On Thu, May 7, 2009 at 6:38 PM, David Brownell davi...@pacbell.net wrote:
Øyvind Harboe wrote:
On Fri, May 8, 2009 at 2:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
Here is my last comment for tonight, promise :)
Before we had a setup where it was possible to use inhandlers, or to not
use inhadlers and place the corresponding logic in the upper layer.
Now
Øyvind Harboe wrote:
I maintain that the whole jtag_add_dr_scan_now and changing of
in_handler functionality must be reverted. Im am not sure about the
exact rev, Öyvind PLEASE, you are at the moment screwing up things for
other people without good cause.
There might be a good idea there
Øyvind Harboe wrote:
You can add your stuff for testing, ok no problem. You can put things in
plase so that I can test and profile potential changes. But you are
stepping on my toes by changing things I work on.
Let me take this oportunity to thank you for finding and reporting these
The situation is very different on embedded host with a bitbang
connection to the target versus PC+USB, or PC + simple ethernet JTAG.
Here are the numbers from the Swedish jury:
Measured with the debug millsecond time output.
STM32 + JLink adapter, Linux on Athlon dual core 2.4 GHz.
Every test
Øyvind Harboe wrote:
On Fri, May 8, 2009 at 9:40 AM, Zach Welch z...@superlucidity.net wrote:
On Fri, 2009-05-08 at 09:33 +0200, Øyvind Harboe wrote:
[snip]
I have to give a bit of thought on how to best to profile this, i.e. to
find the precise location of the culprit.
Any ideas?
This is really a debug issue, and the message is only to developers,
that can easily be handled with an assert(field-in_value != NULL) to
remove extra function calls.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
Øyvind Harboe wrote:
Stop trading USB performance for Zylin performance, stop changing the JTAG
API, improving the implementation is nice though.
Listen to Laurent this time, he is right !!
This is a red herring. I do *NOT* intend to trade USB performance for
zylin performance.
Øyvind Harboe wrote:
On Fri, May 8, 2009 at 9:53 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
Ųyvind Harboe wrote:
On Fri, May 8, 2009 at 9:40 AM, Zach Welch z...@superlucidity.net wrote:
On Fri, 2009-05-08 at 09:33 +0200, Ųyvind Harboe wrote:
[snip]
I have
Øyvind Harboe wrote:
The last of the in_handler changes is coming up. I'm testing it now.
Here is the plan going forward in priority order:
1. Commit to svn head the last change. This change is necessary to
run tests.
2. Fix any functional regressions. I've split most of these changes into
Øyvind Harboe wrote:
So... finally on to working on performance.
Does anyone have any good ideas on how to profile
OpenOCD?
For PC hosted OpenOCD the most crucial thing is to reduce
the # of roundtrips.
Her are my first ideas.
- Count number of times the queue is flushed using a global
Øyvind Harboe wrote:
I saw your post that the patch was broken. I will get right on fixing
it or revert soon.
https://lists.berlios.de/pipermail/openocd-development/2009-May/006250.html
Note that I *have* switched gears now on this project to working exclusively
on addressing functional
I'll give it a go, and I do think I understand what is going on under
the hood in some detail.
Also there are a lot of cleanup to be done.
And the documentation about some finer technical points is somewhere
between bad, nonexsistant or can be found in Dominics thesis paper.
Zach Welch wrote:
This is useful but equally useful, and not dependent on, if we accept
my or Öyvinds ideas about some design issues.
Regards
Magnus
Øyvind Harboe wrote:
Committed.
Profiling feature that counts # of times that the queue is flushed.
The nice thing about this feature is that it works across
)
Info : JTAG Tap/device matched
Øyvind Harboe wrote:
On Fri, May 8, 2009 at 2:29 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
Øyvind Harboe wrote:
I've committed a file testing/profile.txt. I'll see about breaking out
an stm32 to test against too.
It would be interesting if you
Øyvind Harboe wrote:
Here is a first cut of modifying arm7tdmi.c to reduce # of
roundtrips for reading registers.
I'm not going to commit any patches before the weekend
that addresses performance problems only. I'm also
experimenting a little bit with the form that these changes
should
Øyvind Harboe wrote:
Sure, this will work (if there are no silly mistakes) but what is actually
happening here ?
- One specific postprocess function for every variant of in_handler function
used
- The upper level user must know which postprocess function to use in every
specific place, or
Øyvind Harboe wrote:
add_ir_scan is called with just 1 scan_field, then this function sets the
number of scanfields equal to the number of taps without allocating a a
larger scan_field array.
The error will be seen depending on if the out of bounds memory is cleared
to 0 or not.
Zach Welch wrote:
On Fri, 2009-05-08 at 13:49 +0200, Magnus Lundin wrote:
I'll give it a go, and I do think I understand what is going on under
the hood in some detail.
Thank you for providing your explanations. This has been the most
constructive attempt to address the technical
Øyvind Harboe wrote:
I have found it to, IR in bypass returns 0x01 if I recall correctly, so
bypass taps should not be checked, or checked with a correct value.
The flag used to signal no IR check was to set in_handler = NULL;/*
disable verification by default */
Really ugly but you
on hold.
Best regards
Magnus
Zach Welch wrote:
On Fri, 2009-05-08 at 17:05 +0200, Magnus Lundin wrote:
Zach Welch wrote:
On Fri, 2009-05-08 at 13:49 +0200, Magnus Lundin wrote:
[snip]
Zach Welch wrote:
[snip]
* Are you _certain_
Alan Carvalho de Assis wrote:
Hi list,
Today I had the chance to test OpenOCD + J-Link (v. 5.4) on Olimex
LPC-2378-STK.
It worked like a charm.
Then I think main J-Link problem is related to ARM9/ARM11. Or maybe
just specific to i.MX27ADS board.
Best Regards,
Alan
David Brownell wrote:
One of the patches since the merge of the ti_dm355.cfg line-end
update seems to have broken some aspect of scan chain discovery.
See the openocd server startup transcript below, with scan_chain
command debug output. (FWIW, using with an Olimex ft2232 adapter.)
The
This patch, from 1636 to 1637 breaks the cortx targets.
I am not sure why but I really think removing the inhandler
functionallity is NOT ready for production use yet. Better testining is
needed before changes like this.
Regards
Magnus
Øyvind Harboe wrote:
Committed.
### Eclipse Workspace
jtag_execute_queue(), so this chande
rally changes how we handle large reads and writes where reformatting of
received values to corect byte order etc is handled by the jtag layer.
This functionality should be kept ! Revert PLEASE.
Regards
Magnus
Magnus Lundin wrote:
This patch, from 1636 to 1637
Øyvind Harboe wrote:
On Fri, May 8, 2009 at 12:25 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
The problem is that the inhandler is called asynchronosly from the jtag
layer when the indata has been received.
When jtag_add_dr_scan_now(2, fields, TAP_INVALID) is sent then we have
not even
Øyvind Harboe wrote:
On Fri, May 8, 2009 at 1:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
Ųyvind Harboe wrote:
The problem with the fix and the whole change set is that the
fields{1].in_value variable is not assigned any return value until after
jtag_execute_queue
Øyvind Harboe wrote:
On Fri, May 8, 2009 at 1:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote:
Ųyvind Harboe wrote:
The problem with the fix and the whole change set is that the
fields{1].in_value variable is not assigned any return value until after
jtag_execute_queue
Did you look at jtag_add_dr_scan_now() implemenation?
It calls jtag_execute_queue_noclear(), so we *can* use stack variables
here for in_value.
This is basically:jtag_add_dr_scan_now() == jtag_add_dr_scan +
jtag_execute_queue , we have that in the cortex code where it is
Here is my last comment for tonight, promise :)
Before we had a setup where it was possible to use inhandlers, or to not
use inhadlers and place the corresponding logic in the upper layer.
Now inhandlers are supposed to be bad, it is dictated that inhandlers
are bad. I know about the
I was wrong, there is one more comment :)
The problem with out of context in variables (a real problem, I agree,
but not what makes current code misbehave) has nothing to do with
in_handlers, it is really about the in_value field pointing to a
receiving value.
The inhandler simply transforms
Martin Panter wrote:
On 08/05/2009, David Brownell davi...@pacbell.net wrote:
On Thursday 07 May 2009, David Brownell wrote:
http://search.cpan.org/~infinoid/App-SVN-Bisect-0.8/bin/svn-bisect
Well that was a waste of a few hours. It got into a mode
where it kept producing
It think we should keep them (for now). They do not cause any problems,
a helper to fill in defaults is very simple to write.
But it would be interesting to see some example of how they should be
used to accelerate the JTAG Layer Interface.
Please lets us work on more important stuff, 7 step
Added code for new jtag sequence in JLink driver
Tested on LPC2148 and STM32 with both old and new table.
Small changes that might improve stabilitybut it is still unclear why it
sometimes works and sometimes not.
Regards
Magnus
___
Added (BUILD_JLINK==1) condition to us new tables with JLink
Regards
Magnus
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Dirk Behme wrote:
Magnus Lundin wrote:
tangray wrote:
Hi all,
I could not enter debug state when I set DRCR[0] to b1, And I get
the DSCR[1:0] value is b10
any idea?
DRCR:Debug Run Control Register
DSCR:Debug Status and Control Register
these registers is on page 12.4.12 of Cortex
tangray wrote:
Trying to access Debug Reister Interface with mdw I get
omap3.cpu mdw 0x54011d00
0x54011d00 411fc082...A
Looking at Cortex-A8 TRM, it seems OK.
omap3.cpu mdw 0x54011088
AHBAP Cached values: dp_select 0x0, ap_csw
Hi Dirk
Very good, I think we can commit this immediatleay as a place to collect
the info about A8.
I now have a BeagleBoard :), so testing can be made more efficient,
JTAG solution will be working at the end of the week, strange pinout and
low voltage.
The magic sequence for unlocking
Dirk Behme wrote:
Btw.: Is there an option or a possibility to run a script when I
connect e.g. by telnet?
I'm a little tired to always type the commands
jtag tapenable omap3.cpu
target create omap3.cpu cortex_a8 -endian little -chain-position
omap3.cpu
dap apsel 1
omap3.cpu mww
Michael Bruck wrote:
On Sun, May 3, 2009 at 10:38 PM, Rick Altherr kc8...@kc8apf.net wrote:
In the next few weeks I would like to prepare a roadmap document for where
I think a project like this one should go. I will make that available to
this group. That will basically be done to
Dick Hollenbeck wrote:
Laurent Gauch wrote:
Dick Hollenbeck wrote:
/ Are other folks having problems with tab expansion differences between
// editors?
//
// I load jtag.c into two different editors and get two different results
// when tab width is
Gene Smith wrote:
When I load my program and it burns to flash I see this the first time:
Warn : not enough working area available(requested 16384, free 16336)
This warning is expected, the flash program uses 48 bytes for the flash
algorith.
Then on subsequent loads I see:
Warn : not
Now compare the reported start addresses below with table 5-105 in
OMAP35x TRM, SPRUF98B–September 2008,
and table 2-3 in CoreSight Components, and the management registers in
dap info 1
ap identification register 0x04770002
Type is mem-ap APB
ap debugbase 0x8000
ROM table in legacy
Spencer Oliver wrote:
Can anybody tell me more about the content and organisation
of the STM32 Flash Module Information block. I have searched
but not found :(
This should help
http://www.st.com/stonline/products/literature/pm/13259.pdf
I have tried that one, and found The area
Hi
This speculation but worth trying.
For targets where the debug interface is entirely memory mapped into the
target, apart from a thin communications layer, we only need low level
memory read and memory write. Everything else can be scripted in Tcl. I
think this is the situation for
It would be nice to get some comments on the 8 bit sequence for entering
RESET.
I think the reasoning needs to be documented, else we go back to 7 bits?
Agree, or even use shortest path, I think the state transitions should be
shortest path. If a specific driver needs to use a certain path
Hi
I have just started to test a JLink interface, and looking through the
code it seems that the JLINK_OUT_BUFFER_SIZE is wrong. It must be able
to hold tms and tdi out + 4 command bytes.
#define JLINK_OUT_BUFFER_SIZE2*2048+4
Regards,
Magnus
Dick Hollenbeck wrote:
Magnus Lundin wrote:
It would be nice to get some comments on the 8 bit sequence for
entering
RESET.
I think the reasoning needs to be documented, else we go back to 7
bits?
Agree, or even use shortest path, I think the state transitions
should
Patch commited
rev 1556:
Corrected out buffer size and missing jlink_tap_init() call.
Expanded JLink adapter info at startup.
Regards,
Magnus
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
I have now tested JLink against my standard targets,
the good is I have found no problems, the bad is that I not found any
causes of reported problems.
I have checked Michael Fishers STR 711 program, I can connect to target,
write and read momory, use gdb
LPC_H2124 board, good connections,
Michael Fischer wrote:
Hello Magnus,
I have now tested JLink against my standard targets,
the good is I have found no problems, the bad is that I not found any
causes of reported problems.
This is very strange.
Which FW version does your J-Link have?
J-Link ARM V8 compiled
Dick Hollenbeck wrote:
Magnus,
I think we are talking past each other. There are nouns used in your
sentences that need to be defined.
For example search below for state_move.Its meaning is not
clear. We need to take MUCH more time and articulate what problem we
are even talking
Rev 1535
Added arm_adi_v5.c/h to repository, they will replace cortex_swjdp.c/h.
Better conformance to ARM Debug Interface rev 5 documentation and
remoevd code specific to the Cortex-M3 targets.
Regards,
Magnus
___
Openocd-development mailing
Rev 1536
Changed armv7m and cortexm3 to use nev arm_adi_v5 instead of cortex_swjdp.
Added support for accessport ROM table identification, dap command.
Magnus Lundin wrote:
Rev 1535
Added arm_adi_v5.c/h to repository, they will replace cortex_swjdp.c/h.
Better conformance to ARM Debug
Commited
Øyvind Harboe wrote:
Shouldn't these files be deleted from the repository now?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
cortex_swjdp has ben retired and replaced by arm_adi_v5.
Do automake followed by make.
Changing Makefile.am should triger a automake,
Regards
Magnus
Dick Hollenbeck wrote:
This was removed from the repo.
Why?
The project will not build.
Dick
Hi
Rev 1547, Added two commands that just returns values in hex, good for
scripting.
dap baseaddr
dap apid
Next I started playing with Tcl scripts that scans the ROM table and
installed components. This is my first shot at JimTcl in OpenOCD but it
works quite ok.
dapinfo.tcl
Hi
There are some problems with dap info, but it seems the results are
useful anyway.
Her comes my interpretation:
dap info 0
ap debugbase 0x
ap identification register 0x14770001
No ROM table present
This is a MEM-AP port AHB bus with no ROM table. This could be the
Dick Hollenbeck wrote:
Magnus Lundin wrote:
Hi, here are som thoughts after looking throuh some parts of the jtag
subsystem.
What is a stable state ? A state that is unchanged or a state that
is unchanged and has no sideeffects ? Only RESET and PAUSE ?
A stable state is one
I have done breaking up of very large funktion jtag_execute_queue in
ft2232 driver similar (almost identical) to what Zach has done for
jlink driver.
No functional changes.
Submit for testing from trunk or patch for inspection ??
Regards,
Magnus
Hi
jtag_khz ??
do you have code in flash that configures the pll ?
When I test, I get exactly the same behaviour when khz=2000 (FT2232 )
. But it works well for slower speeds.
Once the onboard clock config code has configured the pll (72khz) then I
can use 6000khz without problems.
There are
Øyvind Harboe wrote:
What config script and target board are you using?
I have played a little with the standard scrips but the interface is
basic ft2232 usbjtag layout and nonstandard vid/pid and Serialnumber string.
For the target it is the stm32.cfg but the reset config is:
Øyvind Harboe wrote:
resetting first
the jtag, and this rsets my target also, and then a little later
resetting the Cortex core giving two rests in quick succeion. It works
but I dont like it. For my old LM2S811 reset does not work well, but I
have not had time to really dig in to this, just
The only reason I can think of for a specic numbering is that it might
optimize the gate design in a hardware implementation of the tap state
engine. But this is not a problem for us so thats OK. If we want to
follow JTAG documentation standards (ARM ane IEEE) in our code then the
state names
Confirmed,
tmp is used as u32 in the following for loop.
The bug breaks the reg command and drscan out values (from
Jim_Command_drscan ) but it should not affect an idcode scan.
Patch applied.
Regards,
Magnus
Andy chenee wrote:
hi:
1. for my test,the latest OpneOCD could not work well
The tap state engine will not change any time soon.
Hopefully the statenumbers will stay.
But there will probably be work on shortest path tables, path transition
tables with fixed mumber of tap transition etc. For this type of work I
think an array is a better and less error prone
I think there should be proper attribution for the B8_ macros, after
searching a bit this seems to be the original author.
/*
B8__ macros from the public domain contributions of
*/
OR
/* Binary constant generator macro
By Tom Torfs - donated to the public domain
*/
Dick Hollenbeck wrote:
Magnus Lundin wrote:
The tap state engine will not change any time soon.
Hopefully the statenumbers will stay.
But there will probably be work on shortest path tables, path
transition tables with fixed mumber of tap transition etc. For this
type of work I think
Alain M. wrote:
Zach Welch escreveu:
Hi all,
Here is the current list of outstanding tasks for the OpenOCD project.
I am new to this list and the second motive that I am here is this:
When I use OpenOCD to write a flash (CortexM3) the second Serial port of
the FT2232D has it's
Hi
This is guesswork since I have no hardware to test but ..
I have been looking at old patches from Jeff, and at the current JLink
code. The problems with processor faults that Jeff reports and fixes by
scanning out a nop indicates that the processor executes extra tdi bus
data as
Hi
Do you know if this is an OS X, gdb, J-Link or general OpenOCD problem ?
What happens/does not happen when you try to download ?
Regards,
Magnus
Michael Fischer wrote:
Hello Zach,
* J-Link driver (w/ yellow hardware):
- cure buggy madness (this is my own poorly qualified TODO
Hi
I think yuo can use something like:
targets omap3.cpu
cortex_m3 dap 0
I have never used any target with multiple taps so this is just guessing
from my side.
Regards,
Magnus
Dirk Behme wrote:
Magnus Lundin wrote:
Hi
The following patch is a first step towards support for sevaral AP
there are instructions not handled by the
following block of logic. I added output to see if that is the case.
Cheers,
Zach
On Tue, 2009-04-14 at 00:50 +0200, Magnus Lundin wrote:
Hi,
Is it possible to find out the exact assembly code that kills OpenOCD ?
Let me guess that I could be an immediate
Hi
You are just erasing one sector of the flash memory, 1k, and probalby
your bin file is larger.
Try something like: flash erase_sector 0 0 10
Magnus
Robert Taylor wrote:
Hello,
I'm new to embedded development and I've just bought a STM3210E-EVAL
board and an Olimex ARM-USB-TINY JTAG
Hi
I have commited a patch that gives more readable error reporting for
STM32 flash writing errors.
But still all errors are reported with the error code
ERROR_FLASH_OPERATION_FAILED (-902) as return code wich is not very
helpul about the cause of the error.
My suggestion is to return the
Hi
The following patch is a first step towards support for sevaral AP in
one dap.
- Adds a apsel variable, corresponding to the corresponding field in the
DP SELECT register, to the swjdap structure.
- adds a function swjdp_apselect(swjdp_common_t *swjdp,u8 apsel) to set
this variable.
-
experimentation.
The command names can easily be changed to anything we like, but lets
see if this is useful at all :)
Regards,
Magnus
Rick Altherr wrote:
On Apr 14, 2009, at 12:13 PM, Magnus Lundin wrote:
Hi
The following patch is a first step towards support for sevaral AP in
one dap
Hi,
The STICKY ERROR messages comes when the debugger asks OpenOCD to read
a 32 bit word from address 0xfffe.
This is not a valid STM32 memory address so an AHB bus error is
generated and shows up at the debug interface as a sticky error.
I would say that OpenOCD does exactly what it is
Hi,
Is it possible to find out the exact assembly code that kills OpenOCD ?
Let me guess that I could be an immediate shift or MOVS in thumb mode .
I am not an expert on the single step PC prediction code in
arm_simulate_step(target_t *target, u32 *dry_run_pc) but
there are some tumb
Hi,
The arm7_9 code has implemented run_algorithm_inner which is necessary
for target algorithms that communicates with the host using dcc.
This looks good and I think the other architectures should do the same,
but first I suggest some cleanups:
Add run_algorithm_inner and
Magnus Lundin wrote:
Hi,
The arm7_9 code has implemented run_algorithm_inner which is necessary
for target algorithms that communicates with the host using dcc.
This looks good and I think the other architectures should do the same,
but first I suggest some cleanups:
Add
Spencer Oliver wrote:
This works with a configured 72 MHz clock on the target,
in my case from the preprogrammed board test application.
The performance of the target flash controller is now the main
limiting factor.
I would commit this aswell, this could also be applied to the
Spencer Oliver wrote:
This works with a configured 72 MHz clock on the target,
in my case from the preprogrammed board test application.
The performance of the target flash controller is now the main
limiting factor.
I would commit this aswell, this could also be applied to the
Is it possible the the processor core is held in reset ?
Basic JTAG is working.
It seems that communications with the debug port is also working,
the SWJ-DP OVERRUN messages comes at the right time :), we can add some
diagnostics to test this.
But trying to access memory mapped registers over
101 - 200 of 205 matches
Mail list logo
