Re: [Openocd-development] mem2array/array2mem fixes
Øyvind Harboe wrote: Please test this patch to see if it fixes mem2array/array2mem. This seems to fix Strontium's issue. Unpatched r1800 gives me: -- cut -- version Open On-Chip Debugger 0.2.0-in-development (2009-05-17-07:51) svn:1800 omap3.cpu mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 Runtime error, file command.c, line 453: wrong # args: should be dataval varname width addr nelems omap3.cpu mem2array dataval junk 32 [expr 0x54011000 + 0 * 4] 1 -- cut -- Patched r1800 results in: -- cut -- version Open On-Chip Debugger 0.2.0-in-development (2009-05-17-07:51) svn:1800 omap3.cpu mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 -- cut -- Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] mem2array - i cant get it to work :(
Strontium wrote: Magnus Lundin wrote: 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 this it turns out to really be ocd_mem2array dataval 32 [expr 0x54011000 + $reg_num * 4] 1 Yes, as I said, ocd_mem2array works, because it calls jim_mem2array which passes argc=5 to target_mem2array, and target_mem2array expects argc to equal 5. Its when target_mem2array is called by tcl_target_func that argc = 4 that the call fails. Even though it has been called with the correct parameters. This is a bug. The question is, is the correct fix to make jim_mem2array call target_mem2array with argc=4, like tcl_target_func does, or should tcl_target_func be calling like jim_mem2array does. Could you try https://lists.berlios.de/pipermail/openocd-development/2009-May/006577.html ? See https://lists.berlios.de/pipermail/openocd-development/2009-May/006658.html too. Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
Zach Welch wrote: On Sun, 2009-05-10 at 22:31 +0200, Magnus Lundin wrote: 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 special, sometimes an extra (perhaps unneccessary) round of automake make clean ./configure --enable-jlink --enable-ft2232_libftdi --enable-maintainer-mode--enable-parport make As already mentioned, looking into the code: ocd_mem2array is registered in tclapi_register_commands() in tclapi.c. But: It seems to me that tclapi_register_commands() isn't called anywhere, and even worse, tclapi.c isn't compiled. I even can't find it in any ocd_mem2array is also registered in target.c : target_register_user_commands, line 1302 in head I really suspect that tclapi.c is redundant, but I dont know D'oh. I should have done some more research on my own, but I figured it was safer to bet that I was premature to remove it. But sure enough, your discovery made me look around, and tclapi.c appears to be entirely redundant at this point: ocd_mem2array and ocd_array2mem are in target.c ocd_flash_banks is in flash.c drscan is in jtag.c. So... I was originally correct to remove it, and I have now done so again because I think that it just introduced a substantial regression. The patch has effectively been reversed in r1694. Sorry for the noise. The irony is that I nuked tclapi.c to eliminate possible confusion! It seems that Strontium's mem2array issue is fixed with Øyvind's patch (see previous mail), now :) But seems that my issue isn't :( To remember, my issue was and is that I can't execute 'ocd_mem2array'. r1800 (with Øyvind's patch) gives me -- cut -- version Open On-Chip Debugger 0.2.0-in-development (2009-05-17-07:51) svn:1800 omap3.cpu mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 invalid command name ocd_mem2array_dataval called at file command.c, line 453 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 -- cut -- Most probably I do some stupid thing wrong here, but I can't see it at the moment :( Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] PIC32 openocd status
2009/5/5 Michel Catudal michelcatu...@gmail.com: A project I am working on is to make a programmer for the PIC32 on SuSE Linux. I am looking into implementing the use of the Programming Excecutive in OpenOCD. I have read the documentation from Microchip and it seems straight forward, the OpenOCD implementation is not that clear though. Many important commands are not implemented. Nice project. What is the Jtag tool you are using? And what is the exact status of OpenOCD with PIC32 in terms of debugging and programming? For programming, you can probably use the US$35 PICkit 2 and pk2cmd. But there is no debugging support with PICkit 2 for PIC32. pk2cmd's source codes are also available. http://www.microchip.com/pickit2 It would be great that openocd can work with PIC32 using JTAG. I think Real ICE, ICD 2 and ICD 3 do not use JTAG for debugging PIC32. Last time Spen posted some news on the Microchip Forum. http://www.microchip.com/forums/tm.aspx?m=346142 Since then, it is now quite easy to build gcc toolchain for PIC32 (newlib not ported), pk2cmd also supports PIC32 programming now. So openocd will help a lot. And according to the mailing list, John McCarthy has got flashing partially working. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
On May 17, 2009, at 11:06, Freddie Chopin wrote: Zach Welch pisze: They should have been treated to 'svn mv', because this would have preserved the history available from 'svn log'. First of all - I've tied to do that this way, but TortoiseSVN does not offer such option. It does, but not in an immediately obvious way: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-copy.html Regards, Anders Montonen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
Anders Montonen pisze: It does, but not in an immediately obvious way: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-copy.html I can do it that way, but the effect in a patch is worthless as I can only create info about removal of the file, but the new file is not created. In no way I can make TortoiseSVN create a patch with JUST changing paths and names. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] mem2array/array2mem fixes
I've committed the fix. Though there are actually 4 test cases and I only smoketested them + we have no regression test library. :-) ocd_mem2array xxx omap3.cpu mem2array xxx array2mem xxx omap3.cpu array2mem xxx -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] change ir_scan to bool
On Sun, May 17, 2009 at 11:20 AM, Michael Bruck mbr...@digenius.de wrote: At least the arm11 port has a macro ZU that is intended to be used when size_t is printed. I recently saw a patch that ignored that, but I didn't comment on this error because it is like fighting windmills. Someone who regularly compiles mingw (or a cross-compile farm) would be in a better position to consistently highlight such issues. How about finding some library/implementation of sprintf() that we can statically link with OpenOCD rather than relying on the underlying OS/runtimes? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
-- cut -- version Open On-Chip Debugger 0.2.0-in-development (2009-05-17-07:51) svn:1800 omap3.cpu mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 invalid command name ocd_mem2array_dataval called at file command.c, line 453 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 -- cut -- Most probably I do some stupid thing wrong here, but I can't see it at the moment :( Try w/svn head. Seems to work fine here: Open On-Chip Debugger ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 Target not examined yet mem2array: Read @ 0x54011000, w=4, cnt=1, failed targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- 0: at91eb40a.cpu arm7tdmi little 0 at91eb40a.cpu unknown at91eb40a.cpu mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 Target not examined yet mem2array: Read @ 0x54011000, w=4, cnt=1, failed -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Command name combining with underscores
All, Last year (I think it was mid July) when JimTCL was originally being introduced to OpenOCD, we wanted to have some means to make the transition from old commands to new commands - work easily. At the time we made a collective decision to handle errors like this: Example command line: foo bar dog cat frog First try the command foo - If that fails, insert an underline: foo_bar, I forget how deep we planned on inserting underlines. The plan was - to *CONVERT* all commands to JIM commands over time. It seems that decision UNDERLINE decsion is still causing much confusion today. Case in point, the receint ocd_mem2array() problem ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 invalid command name ocd_mem2array_dataval Perhaps - we should *REMOVE* this feature and *STOP* supporting this silent command transforming step. Thoughts? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 FYI - I wrote the original JimTCL memory functions here last year, sadly my documentation level sort of sucks eh? The intent was to *NEVER* really expose ocd_mem2array that was a builder function. Based on my quick read of what you are doing you should source the file memory.tcl or mmr_helpers.tcl Do this in your CONFIGURE script: source [find tcl/memory.tcl] That file has a number of functions like: memread32 ADDRESS By design, it handles various errors. You might also take a look around find the files: stm32_regs.tcl - and some sam7 versions. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command name combining with underscores
On Sun, May 17, 2009 at 3:49 PM, Duane Ellis open...@duaneellis.com wrote: All, Last year (I think it was mid July) when JimTCL was originally being introduced to OpenOCD, we wanted to have some means to make the transition from old commands to new commands - work easily. At the time we made a collective decision to handle errors like this: Example command line: foo bar dog cat frog First try the command foo - If that fails, insert an underline: foo_bar, I forget how deep we planned on inserting underlines. The plan was - to *CONVERT* all commands to JIM commands over time. It seems that decision UNDERLINE decsion is still causing much confusion today. Case in point, the receint ocd_mem2array() problem ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 invalid command name ocd_mem2array_dataval I'm thinking that the ocd_ prefix should go. It's just confusing. There is an arp_ prefix for the tcl code that implements reset, but I guess that could stay even if we remove the ocd_ prefix Perhaps - we should *REMOVE* this feature and *STOP* supporting this silent command transforming step. With a little bit of care we can probably do this and fix a few bugs usability problems along the way. I don't think it is necessary or worthwhile to break the syntax though. Possibly we should consider removing the arm7_9 command prefix, but the flash prefix should probably stay. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
Strange indeed. Parsing works here... ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 Target not examined yet mem2array: Read @ 0x54011000, w=4, cnt=1, failed -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] change ir_scan to bool
A common way of handling these types of format-string differences for 32/64 bit cases is to define macros named things like PRIX32 which expands to the proper % sequence to print a 32-bit number as hex. We could do something similar for size_t and introduce something like PRIuSIZE. For anything C99-compliant, it would expand to %zu, but for mingw, it would expand to the appropriate size for the bitness of the host. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned On May 17, 2009, at 6:04 AM, Øyvind Harboe wrote: On Sun, May 17, 2009 at 11:20 AM, Michael Bruck mbr...@digenius.de wrote: At least the arm11 port has a macro ZU that is intended to be used when size_t is printed. I recently saw a patch that ignored that, but I didn't comment on this error because it is like fighting windmills. Someone who regularly compiles mingw (or a cross-compile farm) would be in a better position to consistently highlight such issues. How about finding some library/implementation of sprintf() that we can statically link with OpenOCD rather than relying on the underlying OS/runtimes? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
Øyvind Harboe wrote: Strange indeed. Parsing works here... Yes, I believe this ;) The big question is what might be different for me. From your last mail, you use 'at91eb40a' CPU configuration? Maybe the init scripts for this do some magic which is missing for me? What scripts do you source for this, just to have a look. Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
On Sunday 17 May 2009, Duane Ellis wrote:
FYI - I wrote the original JimTCL memory functions here last year, sadly
my documentation level sort of sucks eh?
Documentation? Didn't even know that tcl/* stuff existed. :)
There aren't even any users of the tcl/* stuff in any of
the existing cfg files. And as we know, examples are all
too often substitutes for documentation.
The intent was to *NEVER* really expose ocd_mem2array that was a
builder function. Based on my quick read of what you are doing you
should source the file memory.tcl or mmr_helpers.tcl
Do this in your CONFIGURE script:
source [find tcl/memory.tcl]
That file has a number of functions like: memread32 ADDRESS
Hmm, I asked about this sort of thing not long ago:
https://lists.berlios.de/pipermail/openocd-development/2009-May/006340.html
Nobody knew about memread32 as an answer...
By design, it handles various errors.
Everyone seems to be using mw{b,h,w} instead of memwrite{8,16,32}
and I was the first to seem to notice that the md{b,h,w} siblings
were useless for scripting purposes.
There are also various arm-specific utilities, some to work with
physical addressese (vs, I guess, whatever the current MMU context
or non-context delivers).
These seem like the sorts of things that ought to be builtins,
not library layers...
You might also take a look around find the files: stm32_regs.tcl -
and some sam7 versions.
Hmm, I noticed that chip/atmel/at91/at91sam7x128.tcl (for example)
defines a global AT91C_ID ... which strongly presumes that there's
only one at91 family chip, since those IDs vary between chips.
What I had started to do with some DaVinci stuff is define a
dictionary with various chip-specific symbols, then have the
utlities use the relevant dictionary.
Now, I *like* the idea of having a way to grow libraries of
reusable Jim code to help work with chips, and symbolic names
for registers (or at least controllers) seems essential to that.
But I'm not sure that's quite the right way to start.
- Dave
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
On Sun, May 17, 2009 at 8:02 PM, Dirk Behme dirk.be...@googlemail.com wrote: Ųyvind Harboe wrote: Strange indeed. Parsing works here... Yes, I believe this ;) The big question is what might be different for me. From your last mail, you use 'at91eb40a' CPU configuration? Maybe the init scripts for this do some magic which is missing for me? What scripts do you source for this, just to have a loo Try the command line below to replicate my setup: openocd -f interface/dummy.cfg -f target/at91eb40a.cfg (using configure --enable-dummy to build the dummy driver...) -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Tiff] Potential problem in libtiff when compiled in MinGW
Hello Bob, Sunday, May 17, 2009, 6:44:41 PM, you wrote: BF I see. MinGW depends on whatever library happens to be installed so BF %ll may work on some Windows systems (which happen to have an BF updated library) and not on others. None of the MSVC runtime libraries support %ll, you have to use %I64. Since MinGW uses older msvcrt.dll which is unlikely to be updated (API-wise), that situation will probably remain. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
For reference, this little utility:
# mrw: memory read word, returns value of $reg
proc mrw {reg} {
set value
ocd_mem2array value 32 $reg 1
return $value(0)
}
works fine in my tree, which is still at r1793.
... and yes, I'd be all for removing that hack which
morphs cmd arg1 arg2 ... into cmd_arg1 on typo.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
duane [about stuff in tcl/memory.tcl]
david Hmm, I asked about this sort of thing not long ago:
I've been buried with other tasks and not paying attention much on the
list for a while.. Other things had to take priorities.
david Everyone seems to be using mw{b,h,w} instead of memwrite{8,16,32}
Yea, the problem comes down to this:
There are the old command context based commands
ie: The original way Dominic et al wrote OpenOCD - which are PRE
JimTCL.
And there are the new tcl based commands.
Which was introduced mid last year
Not everything has been transitioned.
The MW{BHW} should really be *removed* - in fact all command context
commands should be deprecated and removed/replaced.
The problem is hurding cats every cat has their own solution, and
every cat thinks *some*other* part (ie: their part) of OpenOCD is more
important to work on, people get mad... upset, and angry :-(
There are also various arm-specific utilities, some to work with
physical addressese (vs, I guess, whatever the current MMU context
or non-context delivers).
Yes, and those commands effect the *current* target (as defined by a
global variable in OpenOCD) nobody has really had multiple targets yet
that I am aware of, I'm sure there that when somebody has a *REAL* dual
core target system things will become very very interesting and lots of
bugs will come out.
When I created the target-as-an-object command system last year, ie:
the omap.cpu command creation, I specifically addressed that - so that
one *COULD* in theory read/write specific targets.
What is *REALLY* missing in terms of documentation is road map
material - intent of certain things, methods, etc. So that people see a
vision of how things can come together to solve a problem.
ie: Why does the the HTTP server exist and the TCL server exist? It's
not what people think. The intent is/was a universal GUI front end, and
the ability to script OpenOCD in a far more universal way then anything
one might do with a libopenocd solution and is *DIRECTLY* related to
the chip.tcl stuff.
BTW - I wrote all of that TCL stuff nearly 9 months ago.
david Hmm, I noticed that chip/atmel/at91/at91sam7x128.tcl (for example)
daviddefines a global AT91C_ID ... which strongly presumes that there's
david only one at91 family chip, since those IDs vary between chips.
In general, atmel has a single set of IP that defines a peripherals, and
they re-use it over and over again across all of the AT91 series parts,
sort of like a we have a uart in our chip library. Other chip
companies do the same thing. All atmel uarts have the same flavor - they
have one uart design - and it has evolved over the years.
david What I had started to do with some DaVinci stuff is define a
david dictionary with various chip-specific symbols, then have the
david utilities use the relevant dictionary.
Good idea! The real trick is to understand how the family goes together.
You also might look a the other top level things in the top level directory.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
Øyvind Harboe wrote: On Sun, May 17, 2009 at 8:02 PM, Dirk Behme dirk.be...@googlemail.com wrote: Ųyvind Harboe wrote: Strange indeed. Parsing works here... Yes, I believe this ;) The big question is what might be different for me. From your last mail, you use 'at91eb40a' CPU configuration? Maybe the init scripts for this do some magic which is missing for me? What scripts do you source for this, just to have a loo Try the command line below to replicate my setup: openocd -f interface/dummy.cfg -f target/at91eb40a.cfg (using configure --enable-dummy to build the dummy driver...) Done: version Open On-Chip Debugger 0.2.0-in-development (2009-05-17-20:48) svn:1801 targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- 0: at91eb40a.cpu arm7tdmi little 0 at91eb40a.cpu unknown ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 Target not examined yet mem2array: Read @ 0x54011000, w=4, cnt=1, failed So this *does* work :) Looks like a Cortex configuration/environment issue then. Thanks Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
So this *does* work :) Looks like a Cortex configuration/environment issue then. Strange indeed. Can you reproduce it w/your target and the dummy driver? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
Øyvind Harboe wrote: So this *does* work :) Looks like a Cortex configuration/environment issue then. Strange indeed. Can you reproduce it w/your target and the dummy driver? openocd -s lib/openocd/ -f interface/dummy.cfg -f board/ti_beagleboard.cfg version Open On-Chip Debugger 0.2.0-in-development (2009-05-17-20:48) svn:1801 target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- 0: omap3.cpu cortex_m3 little 0 omap3.cpu unknown ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 invalid command name ocd_mem2array_dataval called at file command.c, line 453 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 For your reference: ti_beagleboard.cfg is in svn: ./src/target/board/ti_beagleboard.cfg Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
You have to create the target before the init command. One could talk about allowing targets to be created/deleted on the fly, but OpenOCD isn't at that stage today. This works: openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg -c target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu -c init -c ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 Move init and it fails: openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg -c init -c target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu -c ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
On Sunday 17 May 2009, Duane Ellis wrote: david Hmm, I noticed that chip/atmel/at91/at91sam7x128.tcl (for example) daviddefines a global AT91C_ID ... which strongly presumes that there's david only one at91 family chip, since those IDs vary between chips. In general, atmel has a single set of IP that defines a peripherals, and they re-use it over and over again across all of the AT91 series parts, sort of like a we have a uart in our chip library. Other chip companies do the same thing. All atmel uarts have the same flavor - they have one uart design - and it has evolved over the years. Right, but AT91C_ID is a good example of how Atmel changes things between parts. Those IDs are used in two controller-specific ways: defining IRQ lines, and gating clocks (for clocks that can be gated). So when one part may have four UARTs, another may have just two but will add a CAN controller; those IDs will then mean different things. Compare that sam7 part with any of the sam9 parts, for example, or an rm9200. You're correct that those individual controllers haven't tended to vary much. (The AVR32 parts use pretty much the same designs.) That's software-friendly, but not all hardware houses work like that. And in newer designs, Atmel has had to evolve some of their more fundamental things ... running out of pinmux options and module IDs for more complex chips will do that. david What I had started to do with some DaVinci stuff is define a david dictionary with various chip-specific symbols, then have the david utilities use the relevant dictionary. Good idea! The real trick is to understand how the family goes together. And accept that what seems constant for now may well change soon, for most vendors. The next chip iteration is likely to differ in more than just the amount of memory or clock speed. That understanding develops over time, and is encapsulated in code that handles more and more of the family. A dictionary does OK for handling this controller is at a different address differences, and can help address other types of differences. Mostly I see it as a way to structure things ... there may be better ones. Globals won't work. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] doc: mention ETM and ETB (for ARM)
Doc should at least mention the ETM and ETB support found
on some ARM chips. Also include a convention about naming
the ETB tap.
NOTE that (a) I suspect this isn't widely used yet, even
though it's kind of neat, and (b) in some cases the ETM
parameters can be detected from a module query, so it's
just annoying always to need to figure them out and feed
them to oocd.
Doc should at least mention the ETM and ETB support found
on some ARM chips. Also include a convention about naming
the ETB tap.
NOTE that (a) I suspect this isn't widely used yet, even
though it's kind of neat, and (b) in some cases the ETM
parameters can be detected from a module query, so it's
just annoying always to need to figure them out and feed
them to oocd.
---
doc/openocd.texi | 23 +++
1 file changed, 23 insertions(+)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1016,6 +1016,7 @@ See the command ``jtag newtap'' for deta
@item @b{cpu}
@item @b{flash}
@item @b{bs}
+...@item @b{etb}
@item @b{jrc}
@item @b{unknownN} - it happens :-(
@end itemize
@@ -1050,6 +1051,27 @@ helpful - for common programing errors.
If present, the MMU, the MPU and the CACHE should be disabled.
+Some ARM cores are equipped with trace support, which permits
+examination of the instruction and data bus activity. Trace
+activity is controlled through an ``Embedded Trace Module'' (ETM)
+on one of the core's scan chains. The ETM emits voluminous data
+through a ``trace port''. The trace port is accessed in one
+of two ways. When its signals are pinned out from the chip,
+boards may provide a special high speed debugging connector;
+software support for this is not configured by default, use
+the ``--enable-oocd_trace'' option. Alternatively, trace data
+may be stored an on-chip SRAM which is packaged as an ``Embedded
+Trace Buffer'' (ETB). An ETB has its own TAP, usually right after
+its associated ARM core. OpenOCD supports the ETM, and your
+target configuration should set it up with the relevant trace
+port: ``etb'' for chips which use that, else the board-specific
+option will be either ``oocd_trace'' or ``dummy''.
+
+...@example
+etm config $_TARGETNAME 16 normal full etb
+etb config $_TARGETNAME $_CHIPNAME.etb
+...@end example
+
@subsection Internal Flash Configuration
This applies @b{ONLY TO MICROCONTROLLERS} that have flash built in.
@@ -1642,6 +1664,7 @@ JTAG taps. GDB ends up talking via OpenO
@item @b{cpu} - the main CPU of the chip, alternatively @b{foo.arm} and @b{foo.dsp}
@item @b{flash} - if the chip has a flash tap, example: str912.flash
@item @b{bs} - for boundary scan if this is a seperate tap.
+...@item @b{etb} - for an embedded trace buffer (example: an ARM ETB11)
@item @b{jrc} - for JTAG route controller (example: OMAP3530 found on Beagleboards)
@item @b{unknownN} - where N is a number if you have no idea what the tap is for
@item @b{Other names} - Freescale IMX31 has a SDMA (smart dma) with a JTAG tap, that tap should be called the ``sdma'' tap.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] accept target *names* everywhere, not just numbers
Replace get_target_by_num() with get_target():
- Allows target names, not just numbers ... numbers are awkward
for config scripts, given for example a system with several
CPUs or flash chips.
- Slightly shrinks most call sites by removing strtoul() calls.
- Use the same error message everywhere get_target() failure is
being reported ... helps eventual I18N and messaging docs, and
enables some text shrinkage.
Update docs to match.
NOTE: to encourage migration, get_target() should eventually
emit a warning when it sees a numeric target ID.
Replace get_target_by_num() with get_target():
- Allows target names, not just numbers ... numbers are awkward
for config scripts, given for example a system with several
CPUs or flash chips.
- Slightly shrinks most call sites by removing strtoul() calls.
- Use the same error message everywhere get_target() failure is
being reported ... helps eventual I18N and messaging docs, and
enables some text shrinkage.
Update docs to match.
NOTE: to encourage migration, get_target() should eventually
emit a warning when it sees a numeric target ID.
---
doc/openocd.texi| 47 -
src/flash/ecos.c|4 +-
src/flash/flash.c |4 +-
src/flash/lpc3180_nand_controller.c |4 +-
src/flash/mflash.c |4 +-
src/flash/orion_nand.c |4 +-
src/flash/s3c24xx_nand.c|6 +--
src/target/etb.c|4 +-
src/target/etm.c|5 +--
src/target/etm_dummy.c |4 +-
src/target/image.c |7 ++--
src/target/target.c | 55 +++---
src/target/target.h |2 -
src/target/target/ti_dm355.cfg |7 +---
src/target/xscale.c |9 +++--
15 files changed, 89 insertions(+), 77 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -881,6 +881,8 @@ If the chip has 2 targets, use the names
At no time should the name ``target0'' (the default target name if
none was specified) be used. The name ``target0'' is a hard coded name
- the next target on the board will be some other number.
+In the same way, avoid using target numbers even when they are
+permitted; use the right target name(s) for your board.
The user (or board file) should reasonably be able to:
@@ -1679,7 +1681,8 @@ tap which then connects to the TDI pin.
@item @b{Note: Deprecated} - Index Numbers
@* Prior to 28/nov/2008, JTAG taps where numbered from 0..N this
feature is still present, however its use is highly discouraged and
-should not be counted upon.
+should not be counted upon. Update all of your scripts to use
+TAP names rather than numbers.
@item @b{Multiple chips}
@* If your board has multiple chips, you should be
able to @b{source} two configuration files, in the proper order, and
@@ -2022,8 +2025,8 @@ jtag configure DOTTED.NAME -event tap-di
@itemize @bullet
@item @b{NAME}
@* Is the name of the debug target. By convention it should be the tap
-DOTTED.NAME, this name is also used to create the target object
-command.
+DOTTED.NAME. This name is also used to create the target object
+command, and in other places the target needs to be identified.
@item @b{TYPE}
@* Specifies the target type, i.e.: ARM7TDMI, or Cortex-M3. Currently supported targets are:
@comment START types
@@ -2231,7 +2234,7 @@ The @b{flash bank} command is used to co
@example
@b{flash bank} @var{driver} @var{base} @var{size} @var{chip_width}
-@var{bus_width} @var{target#} [...@var{driver_options ...}]
+@var{bus_width} @var{target} [...@var{driver_options ...}]
@end example
@cindex flash bank
@*Configures a flash bank at @var{base} of @var{size} bytes and @var{chip_width}
@@ -2251,8 +2254,9 @@ perhaps configure a GPIO pin that contro
on the flash chip.
@b{flash bank cfi} @var{base} @var{size} @var{chip_width} @var{bus_width}
-@var{target#} [...@var{jedec_probe}|@var{x16_as_x8}]
-...@*cfi flashes require the number of the target they're connected to as an additional
+@var{target} [...@var{jedec_probe}|@var{x16_as_x8}]
+...@*cfi flashes require the name or number of the target they're connected to
+as an additional
argument. The CFI driver makes use of a working area (specified for the target)
to significantly speed up operation.
@@ -2266,12 +2270,13 @@ The @var{jedec_probe} option is used to
@subsubsection lpc2000 options
@cindex lpc2000 options
-...@b{flash bank lpc2000} @var{base} @var{size} 0 0 @var{target#} @var{variant}
+...@b{flash bank lpc2000} @var{base} @var{size} 0 0 @var{target} @var{variant}
@var{clock} [...@var{calc_checksum}]
@*LPC flashes don't require the chip and bus width to be specified. Additional
parameters are the @var{variant}, which may be @var{lpc2000_v1} (older LPC21xx and LPC22xx)
-or @var{lpc2000_v2} (LPC213x, LPC214x, LPC210[123], LPC23xx and LPC24xx),
[Openocd-development] [patch] doc: arm7_9 fast_memory_access
It's the faster mode that's potentially less safe, not the slower one. --- a/src/target/arm7_9_common.c +++ b/src/target/arm7_9_common.c @@ -2591,7 +2591,7 @@ int arm7_9_register_commands(struct command_context_s *cmd_ctx) register_command(cmd_ctx, arm7_9_cmd, dbgrq, handle_arm7_9_dbgrq_command, COMMAND_ANY, use EmbeddedICE dbgrq instead of breakpoint for target halt requests enable|disable); register_command(cmd_ctx, arm7_9_cmd, fast_memory_access, handle_arm7_9_fast_memory_access_command, - COMMAND_ANY, use fast memory accesses instead of slower but potentially unsafe slow accesses enable|disable); + COMMAND_ANY, use fast memory accesses instead of slower but potentially safer accesses enable|disable); register_command(cmd_ctx, arm7_9_cmd, dcc_downloads, handle_arm7_9_dcc_downloads_command, COMMAND_ANY, use DCC downloads for larger memory writes enable|disable); ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On Sunday 17 May 2009, Michael Bruck wrote: - jtag_command_t **last_cmd; - last_cmd = jtag_get_last_command_p(); - - *last_cmd = cmd_queue_alloc(sizeof(jtag_command_t)); - (*last_cmd)-next = NULL; - last_comand_pointer = ((*last_cmd)-next); - (*last_cmd)-type = JTAG_SCAN; + jtag_command_t * cmd = cmd_queue_alloc(sizeof(jtag_command_t)); + + jtag_queue_command(cmd); + + cmd-type = JTAG_SCAN; Seems like a goodly fix ... but, couldn't all of those be wrapped up in a single function sort of like cmd = jtag_alloc_and_queue(JTAG_SCAN); Or STATEMOVE, PATHMOVE, etc. Agreed that queue_command() logic is exactly the error-prone stuff that really *needs* encapsulation; it should probably stay separate even with an alloc_and_queue(). - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On May 17, 2009, at 1:43 PM, David Brownell wrote: On Sunday 17 May 2009, Michael Bruck wrote: - jtag_command_t **last_cmd; - last_cmd = jtag_get_last_command_p(); - - *last_cmd = cmd_queue_alloc(sizeof(jtag_command_t)); - (*last_cmd)-next = NULL; - last_comand_pointer = ((*last_cmd)-next); - (*last_cmd)-type = JTAG_SCAN; + jtag_command_t * cmd = cmd_queue_alloc(sizeof(jtag_command_t)); + + jtag_queue_command(cmd); + + cmd-type = JTAG_SCAN; Seems like a goodly fix ... but, couldn't all of those be wrapped up in a single function sort of like cmd = jtag_alloc_and_queue(JTAG_SCAN); Or STATEMOVE, PATHMOVE, etc. Agreed that queue_command() logic is exactly the error-prone stuff that really *needs* encapsulation; it should probably stay separate even with an alloc_and_queue(). - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Rather than combine them, I'd like to see jtag_queue_command() enforce validation of the command to be enqueued. Then the patterns would be: cmd = cmd_queue_alloc(); cmd-type = JTAG_SCAN; jtag_queue_command(cmd); Otherwise, you place a command in the queue before it is filled out. This works fine today where the JTAG queue is manually flushed, but if we ever went to a opportunistic queue draining scheme (device driver pulls next item off queue automatically when a command finishes), you could get bogus commands being executed. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On Sunday 17 May 2009, Rick Altherr wrote: Rather than combine them, I'd like to see jtag_queue_command() enforce validation of the command to be enqueued. Then the patterns would be: cmd = cmd_queue_alloc(); cmd-type = JTAG_SCAN; Then how about passing JTAG_* to the allocator? Related approach: command-specific allocators, which take the parameters that will be fed to each command. jtag_queue_command(cmd); Otherwise, you place a command in the queue before it is filled out. Yeah, that bothered me a bit too, but it *is* the current idiom. Some jtag_queue_scan(...) calls -- allocate and set up each flavor of command, then queue it -- could address that issue *and* keep to the current idiom. This works fine today where the JTAG queue is manually flushed, but if we ever went to a opportunistic queue draining scheme (device driver pulls next item off queue automatically when a command finishes), you could get bogus commands being executed. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] doc -- working area
Move description of the working area setup from the description
of the old deprecated syntax to go with $TARGET configure calls.
Mention that the ARM DCC download support needs working area.
Move description of the working area setup from the description
of the old deprecated syntax to go with $TARGET configure calls.
Mention that the ARM DCC downlod support needs working area.
---
doc/openocd.texi | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -2082,13 +2082,23 @@ command, and in other places the target
@section Target Config/Cget Options
These options can be specified when the target is created, or later
via the configure option or to query the target via cget.
+
+You should specify a working area if you can; typically it uses some
+on-chip SRAM. Such a working area can speed up many things, including bulk
+writes to target memory; flash operations like checking to see if memory needs
+to be erased; GDB memory checksumming; and may help perform otherwise
+unavailable operations (like some coprocessor operations on ARM7/9 systems).
@itemize @bullet
@item @b{-type} - returns the target type
@item @b{-event NAME BODY} see Target events
-...@item @b{-work-area-virt [ADDRESS]} specify/set the work area
-...@item @b{-work-area-phys [ADDRESS]} specify/set the work area
+...@item @b{-work-area-virt [ADDRESS]} specify/set the work area base address
+which will be used when an MMU is active.
+...@item @b{-work-area-phys [ADDRESS]} specify/set the work area base address
+which will be used when an MMU is inactive.
@item @b{-work-area-size [ADDRESS]} specify/set the work area
-...@item @b{-work-area-backup [0|1]} does the work area get backed up
+...@item @b{-work-area-backup [0|1]} does the work area get backed up;
+by default, it doesn't. When possible, use a working_area that doesn't
+need to be backed up, since performing a backup slows down operations.
@item @b{-endian [big|little]}
@item @b{-variant [NAME]} some chips have variants OpenOCD needs to know about
@item @b{-chain-position DOTTED.NAME} the tap name this target refers to.
@@ -2144,15 +2154,6 @@ still use this that need to be converted
@end example
@* The target# is a the 0 based target numerical index.
-This command specifies a working area for the debugger to use. This
-may be used to speed-up downloads to target memory and flash
-operations, or to perform otherwise unavailable operations (some
-coprocessor operations on ARM7/9 systems, for example). The last
-parameter decides whether the memory should be preserved
-(@var{backup}) or can simply be overwritten (@var{nobackup}). If
-possible, use a working_area that doesn't need to be backed up, as
-performing a backup slows down operation.
-
@node Flash Configuration
@chapter Flash programming
@cindex Flash Configuration
@@ -2810,7 +2811,7 @@ speeds, like the 32kHz startup clock of
@*Enable the use of the debug communications channel (DCC) to write larger (128 byte)
amounts of memory. DCC downloads offer a huge speed increase, but might be potentially
unsafe, especially with targets running at very low speeds. This command was introduced
-with OpenOCD rev. 60.
+with OpenOCD rev. 60, and requires a few bytes of working area.
@end itemize
@subsection ARM720T specific commands
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On Sun, May 17, 2009 at 10:54 PM, Rick Altherr kc8...@kc8apf.net wrote: On May 17, 2009, at 1:43 PM, David Brownell wrote: On Sunday 17 May 2009, Michael Bruck wrote: - jtag_command_t **last_cmd; - last_cmd = jtag_get_last_command_p(); - - *last_cmd = cmd_queue_alloc(sizeof(jtag_command_t)); - (*last_cmd)-next = NULL; - last_comand_pointer = ((*last_cmd)-next); - (*last_cmd)-type = JTAG_SCAN; + jtag_command_t * cmd = cmd_queue_alloc(sizeof(jtag_command_t)); + + jtag_queue_command(cmd); + + cmd-type = JTAG_SCAN; Seems like a goodly fix ... but, couldn't all of those be wrapped up in a single function sort of like cmd = jtag_alloc_and_queue(JTAG_SCAN); Or STATEMOVE, PATHMOVE, etc. Agreed that queue_command() logic is exactly the error-prone stuff that really *needs* encapsulation; it should probably stay separate even with an alloc_and_queue(). I did not primarily want to compact code but separate layers. The function wraps the queue manipulation. The data structure initialization itself is much more code than just the type field so I don't like the idea of tearing it apart. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Rather than combine them, I'd like to see jtag_queue_command() enforce validation of the command to be enqueued. Then the patterns would be: cmd = cmd_queue_alloc(); cmd-type = JTAG_SCAN; jtag_queue_command(cmd); Otherwise, you place a command in the queue before it is filled out. This works fine today where the JTAG queue is manually flushed, but if we ever went to a opportunistic queue draining scheme (device driver pulls next item off queue automatically when a command finishes), you could get bogus commands being executed. While I agree in principle I would like to get this patch through first and discuss this suggestion later. My patches are purely code restructuring that should *not* change the algorithms at all. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On Sun, May 17, 2009 at 11:15 PM, David Brownell davi...@pacbell.net wrote: On Sunday 17 May 2009, Rick Altherr wrote: Rather than combine them, I'd like to see jtag_queue_command() enforce validation of the command to be enqueued. Then the patterns would be: cmd = cmd_queue_alloc(); cmd-type = JTAG_SCAN; Then how about passing JTAG_* to the allocator? Related approach: command-specific allocators, which take the parameters that will be fed to each command. This is going towards an OO approach. I am no against that, but I would like to get this patch through independantly of this wider discussion. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On Sunday 17 May 2009, Michael Bruck wrote: I did not primarily want to compact code but separate layers. The function wraps the queue manipulation. The data structure initialization itself is much more code than just the type field so I don't like the idea of tearing it apart. I understand. But I think there's also benefit to getting rid of other common code. Every line of code that doesn't need to be written is a win. :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] ARM11 cleanup stale dependencies with generic arm code; added comments and whitespace fixes
- remove stale interdepencies between arm11 and arm7_9_common - added comments - fixed some indentation Michael openocd-arm11-small-fixes Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On May 17, 2009, at 2:17 PM, Michael Bruck wrote: ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Rather than combine them, I'd like to see jtag_queue_command() enforce validation of the command to be enqueued. Then the patterns would be: cmd = cmd_queue_alloc(); cmd-type = JTAG_SCAN; jtag_queue_command(cmd); Otherwise, you place a command in the queue before it is filled out. This works fine today where the JTAG queue is manually flushed, but if we ever went to a opportunistic queue draining scheme (device driver pulls next item off queue automatically when a command finishes), you could get bogus commands being executed. While I agree in principle I would like to get this patch through first and discuss this suggestion later. My patches are purely code restructuring that should *not* change the algorithms at all. Michael I agree. I'll get to reviewing the patches in depth tonight and hopefully get them committed. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PIC32 openocd status
Xiaofan Chen a écrit : 2009/5/5 Michel Catudal michelcatu...@gmail.com: A project I am working on is to make a programmer for the PIC32 on SuSE Linux. I am looking into implementing the use of the Programming Excecutive in OpenOCD. I have read the documentation from Microchip and it seems straight forward, the OpenOCD implementation is not that clear though. Many important commands are not implemented. Nice project. What is the Jtag tool you are using? And what is the exact status of OpenOCD with PIC32 in terms of debugging and programming? None yet but I will use olimex tiny jtag device. I will need to make a little adapter for it since the connector doesn't have the same pinout. At this point I am just studying the subject. According to the Microchip flash programming documentation, the best approach would be to use the Programming Executive. The programming executive is available as part of the programmer that Microchip has released the source. Obviously I can't tag that with the source of OpenOCD but will compile it in to make the binary. The key is not to violate either the GPL or Microchip's licence. For programming, you can probably use the US$35 PICkit 2 and pk2cmd. But there is no debugging support with PICkit 2 for PIC32. pk2cmd's source codes are also available. http://www.microchip.com/pickit2 I saw that and may purchase it if there is support for Linux as I don't have any windows to work with at home. I use windows at work but I don't want to see that crap on my own computer. It would be great that openocd can work with PIC32 using JTAG. I think Real ICE, ICD 2 and ICD 3 do not use JTAG for debugging PIC32. I am aware of that, that is why I think that it would be easier for debugging when we get PIC32 supported. Last time Spen posted some news on the Microchip Forum. http://www.microchip.com/forums/tm.aspx?m=346142 Since then, it is now quite easy to build gcc toolchain for PIC32 (newlib not ported), pk2cmd also supports PIC32 programming now. So openocd will help a lot. And according to the mailing list, John McCarthy has got flashing partially working. Partially is the key. He can't erase the whole thing so that makes it useless for now. As I look at the code I see that most of the code is commented out so I assumed that it is not working code. That was the reason I asked on this newsletter to see if there is more work done that appears to be. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] NAND documentation? My current notes...
The following are some notes I put together about the nand commands based on reading the source code. I plan to turn them into documentation sometime later, maybe by this time next week. I've seen no documentation on the NAND commands; that seems like a significant omission. Meanwhile I thought I'd send them around for comments and corrections. The == comments are things which seem like they deserve some action other than documenting the current status. One example is removing (or at least disabling) the nand copy command until it gets implemented. - Dave NAND COMMANDS = At this writing: - Only NAND devices with 512 or 2048 byte pages are handled properly. Older devices with 256 byte pages are rejected. == Erm, aren't chips with 4K pages mis-handled? At least in some paths. - ECC codes can be generated when pages are written, but are not used to correct errors when data is read ... unless maybe the underlying driver has a read_page() method which does so. - Writing a file to NAND, or reading it from NAND, ignores bad block markers. == Worth fixing, yes?? Just skipping bad blocks would match one common usage. If not, then at least report errors instead of writing there... - Every NAND device is associated with a target. == Hmm, so maybe that target should be stored in the NAND device instead of the controller-private data. And the lookup should be done by the NAND core not the individual drivers. Or ... should the syntax be TARGET nand ... since the drivers are generally SoC-specific? - Nothing verifies that pages are erased before writing. == Is that the same as NOR flash does? The way to use these starts with: nand device CONTROLLER TARGET [controller-options] ... to declare each NAND chip. For chips with two halves (e.g. a 2 GByte chip with two 1GB halves), declare each half separately. nand info ... to see what number it was given nand probe NUM ... to see what sort of chip is there Then you can use write to transfer data from a file to the NAND chip, or dump to go the other direction. Configuration - nand device CONTROLLER TARGET [controller-options] There are several built-in controllers, some of which have controller-specific options or controller-specific commands. This *must* go into a config/init script. lpc3180 - extra parameter: clock frequency - special command: lpc3180 select NUM [mlc|slc] There are two NAND controllers, one for SLC chips and the other for MLC. If a parameter is given, it selects that controller. The currently selected controller is displayed unless there is an error. - MLC controller seems to use hardware ECC logic... ? orion - extra parameter: address for the NAND chip - no special commands s3c2410 s3c2412 s3c2440 s3c2443 - no extra parameters - no special commands nand list Prints a one-line summary of each device found, numbered from zero. Note that un-probed devices show no details. nand probe NUM Probes the specified device to determine key characteristics including size, manufacturer, page size, and erase size Basic I/O - nand dump NUM filename offset length [oob_raw|oob_only] Reads binary data from the NAND chip and writes it to the file, starting at the specified offset. The offset and length must be an exact multiple of the chip's page size. No error correction is done on the data that's read, unless the controller has a read_page() which does that transparently. By default, only page data is saved to the specified file. Two options allow the OOB data to be saved: - oob_raw ... output file interleaves data and OOB data. - oob_only ... output file has only raw OOB data. nand erase NUM block_first block_last Erases blocks from first to last (inclusive), excepting bad blocks. Checks for bad blocks first, if needed. nand write NUM filename offset [oob_raw|oob_only|oob_softecc|oob_softecc_kw]* Writes binary data from the file into the specified NAND chip, starting at the specified offset. Those pages should already have been erased. The offset must be an exact multiple of the chip's page size. Only full pages are written, and any extra space on the last page will be filled with 0xff bytes. (That includes OOB data, if oob_raw is used.) Unless one or more of the optional oob_* parameters is provided, no OOB data is written. Provide only one oob_* paramater. == No
Re: [Openocd-development] PIC32 openocd status
2009/5/18 Michel Catudal michelcatu...@gmail.com: For programming, you can probably use the US$35 PICkit 2 and pk2cmd. But there is no debugging support with PICkit 2 for PIC32. pk2cmd's source codes are also available. http://www.microchip.com/pickit2 I saw that and may purchase it if there is support for Linux as I don't have any windows to work with at home. I use windows at work but I don't want to see that crap on my own computer. Yes pk2cmd works under Linux and Mac OS X along with Windows. Last time I was also able to make it work under FreeBSD with the beta USB stack from HPS. You can download pk2cmd source from the above link. We also have a mailing list to support it. http://groups.google.com/group/pickit-devel -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PIC32 openocd status
It would be great that openocd can work with PIC32 using JTAG. I think Real ICE, ICD 2 and ICD 3 do not use JTAG for debugging PIC32. I am aware of that, that is why I think that it would be easier for debugging when we get PIC32 supported. Pic32 has 2 debug interfaces. 4 Wire JTAG. And a pin count compressed version of Jtag which is serialised over 2 wires (ICSP). The protocol is the same as JTAG, the electrical interface is the only thing that differs. 2 wire mode should be able to be driven using a FT2232 type device, in a similar fashion to I2C (Tie TDI and TDO together). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PIC32 openocd status
On Sunday 17 May 2009, Strontium wrote: Pic32 has 2 debug interfaces. 4 Wire JTAG. And a pin count compressed version of Jtag which is serialised over 2 wires (ICSP). The protocol is the same as JTAG, the electrical interface is the only thing that differs. 2 wire mode should be able to be driven using a FT2232 type device, in a similar fashion to I2C (Tie TDI and TDO together). Is that 2-wire mode the same one that the JTAG folk have been working with, or is it specific to Microchip? Do you know? Nexus, for example, has both 2-wire and 4-wire/JTAG flavors. Eventually one might expect OpenOCD to support that standard 2-wire interface. ISTR that one configuration can drive it directly from standard JTAG connectors. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PIC32 openocd status
On Mon, May 18, 2009 at 8:58 AM, David Brownell davi...@pacbell.net wrote: On Sunday 17 May 2009, Strontium wrote: Pic32 has 2 debug interfaces. 4 Wire JTAG. And a pin count compressed version of Jtag which is serialised over 2 wires (ICSP). The protocol is the same as JTAG, the electrical interface is the only thing that differs. 2 wire mode should be able to be driven using a FT2232 type device, in a similar fashion to I2C (Tie TDI and TDO together). This is wrong. ICSP is Microchip's proprietory protocol for programming and debugging. The ICSP module is independent from the EJTAG module in PIC32. You can read Chapter 33 of the PIC32MX Family Manual for more information. The ICSP debugging protocol is kept secret by Microchip and Microchip does not want to released to public. NDA access might be possible for certain 3rd party. The ICSP programming protocol is open to the public through the programming specification. To use ICD, an external system that supports ICD must load a debugger executive program into the microcontroller. This is automatically handled by many debugger tools, such as the MPLAB IDE. For PIC32MX devices, the program is loaded into the last page of the Boot Flash memory space. When not debugging, the application is free to use the last page of Boot Flash Memory. PIC32MX ICSP supports standard debugging functions including memory and register viewing and modification. Breakpoints can be set and the program execution may be stopped or started. In addition to these functions registers or memory contents can be viewed and modified while the CPU is running. The debug executive hex files are available from MPLAB installation. Microchip's tools like Real ICE, ICD 3, ICD 2 do not use EJTAG. But JTAG support is available from 3rd party. http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGEnodeId=2602 Is that 2-wire mode the same one that the JTAG folk have been working with, or is it specific to Microchip? Do you know? As answered before, the 2-wire ICSP is not JTAG and the only way to know it is through reverse engineering. The only project I know of is the Piklab project which tries to support ICSP debugging with ICD 2. Anyway, to openocd, it is possible to support JTAG debugging/programming. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PIC32 openocd status
On Mon, May 18, 2009 at 10:06 AM, Strontium strnty...@gmail.com wrote: This is wrong. ICSP is Microchip's proprietory protocol for programming and debugging. The ICSP module is independent from the EJTAG module in PIC32. You can read Chapter 33 of the PIC32MX Family Manual for more information. I didn't make it up. I read it. PIC32MX Flash Programming Specification 61145D.pdf : Plus PIC32MX talks about debugging using EJTAG. EJTAG is designed for debugging. However that same functionality can be used to allow programming. PIC do not need to re-specify EJTAG, as that is available from MIPS. I have found no suggestion that the PIC32 does not implement a compliant EJTAG core, and as ICSP is just de-multiplexed into 4 wire jtag internally, there is no reason why EJTAG operations will not operate as expected over ICSP. PIC32MX supports EJTAG, no doubt about it. I am saying the ICSP module is different from the EJTAG. I am thinking that the ICSP programming and EJTAG programming interface may indeed share the same protocol internally as per the programming specification. But I am 100% sure that ICSP debugging is different from the EJTAG debugging. And I am also 100% sure that existing Microchip debuggers for PIC32 (ICD 2, ICD 3 and Real ICE) do not speak EJTAg for debugging. Example: http://www.microchip.com/forums/tm.aspx?m=414877 You have to disable JTAG port if using MPLAB ICD 2/3 and Real ICE for debugging since they use ICSP debugging. Microchip PIC32 starter kit and PIC32 USB satrter kit do use JTAG for debugging. Real ICE also has the trace function with an add-on. There are lots of MIPS chips that have an EJTAG core. An EJTAG implementation in OpenOCD would be awesome. PIC32 is a nice cheap platform to develop and test this with. I agree with this one. As I mentioned before, it would be good for OpenOCD to support EJTAG of PIC32MX. 3rd parties already offers this possibility now (Ashling, Macraigor Systems, and maybe Green Hill). And the two starter kits also offers JTAG debugging within MPLAB. So it is definitely possible. Actually I think it is already partially supported by Openocd according to Spen. http://www.microchip.com/forums/tm.aspx?m=346142 Since ICSP debugging protocol is closed, it is very difficult to support it. So the only choice for debugging is EJTAG. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] AT91SAM7X256 Flash and verify_image
Hey all, I've been playing a bit with my AT91SAM7X-EK (AT91SAM7X256) development board from Atmel and doing the whole flash, verify, run dance. It seems that the verify image may be a bit broken. For some reason, it keeps kicking the target into the run mode when I tell it to verify. By the looks of the debug output, it has to do it, but for some reason it thinks the board isn't halting although I can see that the board isn't actually doing anything. The PWM program just makes some LEDs dim in and out, so I can see when it isn't running. Other than that, the SAM7 flash stuff seems to work really well. I ran through some tests to make sure I could write and read different things both from telnet and GDB, so I think the new driver should be good for the AT91SAM7x256. I've included my steps and the level 3 debug output for the verify_image piece. reset halt JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3) JTAG Tap/device matched srst pulls trst - can not reset into halted mode. Issuing halt after reset. target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x40d3 pc: 0x00100f50 flash write_bank 0 /home/dnglaze/workspace/pwm.bin 0 wrote 6464 byte from file /home/dnglaze/workspace/pwm.bin to flash bank 0 at offset 0x in 1.189278s (5.307842 kb/s) verify_image /home/dnglaze/workspace/pwm.bin 0x10 timed out while waiting for target halted error executing arm7_9 crc algorithm target not halted Runtime error, file command.c, line 453: Debug Level 3 output after verify_image: Debug: 668 440555 command.c:88 script_command(): script_command - verify_image Debug: 669 440556 command.c:105 script_command(): script_command - verify_image, argv[0]=ocd_verify_image Debug: 670 440556 command.c:105 script_command(): script_command - verify_image, argv[1]=/home/dnglaze/workspace/pwm.bin Debug: 671 440556 command.c:105 script_command(): script_command - verify_image, argv[2]=0x10 Debug: 672 440556 configuration.c:83 find_file(): found /home/dnglaze/workspace/pwm.bin Debug: 673 440556 configuration.c:83 find_file(): found /home/dnglaze/workspace/pwm.bin Debug: 674 440556 image.c:1002 image_calculate_checksum(): Calculating checksum Debug: 675 440557 image.c:1033 image_calculate_checksum(): Calculating checksum done Debug: 676 440557 target.c:807 target_alloc_working_area(): allocating new working area Debug: 677 440557 target.c:1230 target_write_u32(): address: 0x0020, value: 0xe1a02000 Debug: 678 440557 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0004 Debug: 679 440673 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0005 Debug: 680 440680 target.c:1230 target_write_u32(): address: 0x0024, value: 0xe3e0 Debug: 681 440680 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0004 Debug: 682 440790 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0005 Debug: 683 440792 target.c:1230 target_write_u32(): address: 0x0028, value: 0xe1a03001 Debug: 684 440792 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0004 Debug: 685 440899 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0005 Debug: 686 440901 target.c:1230 target_write_u32(): address: 0x002c, value: 0xe3a04000 Debug: 687 440901 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0004 Debug: 688 441008 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0005 Debug: 689 441010 target.c:1230 target_write_u32(): address: 0x00200010, value: 0xea0b Debug: 690 441010 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0004 Debug: 692 441117 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0005 Debug: 693 441119 target.c:1230 target_write_u32(): address: 0x00200014, value: 0xe7d21004 Debug: 694 441119 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0004 Debug: 695 441228 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0005 Debug: 696 441232 target.c:1230 target_write_u32(): address: 0x00200018, value: 0xe59f7030 Debug: 697 441232 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0004 Debug: 698 441341 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0005 Debug: 699 441343 target.c:1230 target_write_u32(): address: 0x0020001c, value: 0xe0200c01 Debug: 700 441343 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0004 Debug: 701 441450 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0005 Debug: 702 441452 target.c:1230 target_write_u32(): address: 0x00200020, value: 0xe3a05000 Debug: 703 441452 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0004 Debug: 705 441559 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0005 Debug: 706 441561 target.c:1230 target_write_u32(): address: 0x00200024, value: 0xe350 Debug: 707 441561 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0004 Debug: 708 441669 embeddedice.c:363 embeddedice_write_reg(): 0: 0x0005 Debug: 709 441671 target.c:1230 target_write_u32(): address: 0x00200028, value: 0xe1a06080
Re: [Openocd-development] JTAG, FT2232 and JLink
On Friday 15 May 2009, Øyvind Harboe wrote: So apply this patch? Can anyone test? jtagpatch.txt It failed for me on an ft2232 device. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd c99 - and the compiler
On May 17, 2009, at 6:16 PM, Duane Ellis wrote: I have an observation I'd like to confirm: I missed the earlier email traffic about c99 etc - and all that sort of stuff. In all cases is is my belief that the *ONLY* compiler that is used to build OpenOCD is GCC, and nothing but GCC, period. I suspect GCC is of some recent vintage - ie: 3.4 (cygwin) or later on all supported platforms. Is that a correct observation? Linux - Obvious. Cygwin - Obvious. MingW - Obvious. MacOSX - It's GCC correct? Yes, it's GCC. At least for now. Soon it will be clang. Is there any other compiler that is *really* used? If so, please name it. I don't think there is. There have been attempts to use VC++. If it is GCC, then tell me, why is C99 (a 10 year old standard) not the default? Why is all GNU features not the default? We're moving towards C99 being the default, but using GNU extensions is a bit much. I'd like to at least leave the option of another compiler. Why pretend something else is going to be used? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG, FT2232 and JLink
On May 17, 2009, at 9:03 PM, David Brownell wrote: On Friday 15 May 2009, Øyvind Harboe wrote: So apply this patch? Can anyone test? jtagpatch.txt It failed for me on an ft2232 device. Hmm. It looks like the jtag.c changes turn on the new short sequence table for FT2232 and JLink even though the drivers aren't ready. That should be a one-line change to that patch. Once we bring in the FT2232 patch, we can reenable the short table for FT2232. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] whitespace cleanup for src/flash/*nand*
On May 17, 2009, at 1:14 PM, David Brownell wrote: flash.patch___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Committed revision 1802. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] doc: mention ETM and ETB (for ARM)
On May 17, 2009, at 1:29 PM, David Brownell wrote: Doc should at least mention the ETM and ETB support found on some ARM chips. Also include a convention about naming the ETB tap. NOTE that (a) I suspect this isn't widely used yet, even though it's kind of neat, and (b) in some cases the ETM parameters can be detected from a module query, so it's just annoying always to need to figure them out and feed them to oocd. doc-trace.patch___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Committed revision 1803. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] accept target *names* everywhere, not just numbers
On May 17, 2009, at 1:18 PM, David Brownell wrote: Replace get_target_by_num() with get_target(): - Allows target names, not just numbers ... numbers are awkward for config scripts, given for example a system with several CPUs or flash chips. - Slightly shrinks most call sites by removing strtoul() calls. - Use the same error message everywhere get_target() failure is being reported ... helps eventual I18N and messaging docs, and enables some text shrinkage. Update docs to match. NOTE: to encourage migration, get_target() should eventually emit a warning when it sees a numeric target ID. etm.patch___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Committed revision 1804. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] doc: arm7_9 fast_memory_access
On May 17, 2009, at 1:31 PM, David Brownell wrote: mem.patch Committed revision 1805. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] doc -- working area
On May 17, 2009, at 2:16 PM, David Brownell wrote: Move description of the working area setup from the description of the old deprecated syntax to go with $TARGET configure calls. Mention that the ARM DCC download support needs working area. doc-working.patch___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Committed revision 1806. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ARM11 cleanup stale dependencies with generic arm code; added comments and whitespace fixes
On May 17, 2009, at 2:40 PM, Michael Bruck wrote: - remove stale interdepencies between arm11 and arm7_9_common - added comments - fixed some indentation Michael openocd-arm11-small- fixes___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Is there someone more familiar with the ARM11 code that can comment on this? From my knowledge, ARM11 is an ARMv6 part and shouldn't have a dependency on the ARMv4/5 code. Sadly, I don't know enough about OpenOCD's implementation of the ARM target support to know if separating them is correct. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD and different versions of J-Link
2008/12/25 Michel Catudal michelcatu...@gmail.com: I could not get my older black j-link devices to work while the newer yellow one works. I am curious as to what the basic difference would be between the two. I tested them at work and they were working just as good on windows as the yellow one with IAR 5.2. (I don't use windows at home) Sorry to rehash this thread as I am interested in this topic as well. I have both black J-link and yellow one at work. Yellow ones are mostly of V5/V6 (and V7?) firmware. The one I have is for V6. The black one I have is of the old V3 version. The MCU used is different as far as I know. It seems to me that the Black one is using a Renesas MCU (M16C?). The yellow one seems to use AT91SAM7S. The speed difference is big. V1/2/3/4 supports 4MHz JTAG and V5/6/7 support 12MHz JTAG. http://www.segger.com/jlink.html Last time I tried both with LPC-2148 and LPC-2468. The yellow one seems to work with Openocd. The black one does not. Both works under Windows with IAR 4.42/5.20/5.30. Both also seem to work with the Segger Linux beta software. There is also a new J-Link Pro with Ethernet/USB interface. It is compatible with J-Link so I assume it will work with OpenOCD as well. It is said that it is using AT91SAM7X256 according to some websites. http://www.segger.com/jlinkpro.html -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
