Re: [Openocd-development] Need help with mips32 74k core bcm4716
On Fri, 6 Nov 2009, Tornado wrote: > Im working with a router WRT320N with broadcom 4716 processor, mips32 > 74k core. I have no information to speak of on this board, I am used to > an ir length of 5 or 8 for broadcom CPU's, Openocd complains about 5 or > 8, with an error a bit 8. I have tried detection with a few other > applications, and they both tell me IR length is 32. > > the IDCODE seems to be detected correctly, but the IMPCODE is always > different, as a matter of fact, if I change the define for IDCODE to > IMPCODE, I still get IDCODE, its as if the board is locked, and will > only give up IDCODE. > > Q. How can I correctly identify the IR length, etc ? knowing I have no > access to documentation. I don't know the exact commands to do this in OpenOCD (hopefully others can fill in the details), but it is theoretically possible. The JTAG standard specifies that the bottom 2 bits of IR are "01" when it is captured, so to work out the IR lengths of the entire chain, step the JTAG TAP to IRSHIFT, via IRCAPTURE, and then clock a long string of 1s into TDI. You should get a string of 1s back, preceded by images of the IRs in the chain, each ending in 01. For example, if you had a chain with an IR length of 4 followed by an IR length of 6, you should see: 1010001 coming back, with right-most digits coming out of TDO first. You may need a tool other than OpenOCD to do this scan, and then plug in the irlength values one you've worked them out. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] USBprog adapter failure to correctly scan IDCODEs
The current code for the USBprog adapter fails right after init when trying to do the DRSCAN for IDCODEs with: Info : 284 201 core.c:948 jtag_examine_chain_display(): JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3) Warn : 285 201 core.c:986 jtag_examine_chain_end(): Unexpected idcode after end of chain: 480 0x80ff Warn : 286 201 core.c:986 jtag_examine_chain_end(): Unexpected idcode after end of chain: 512 0x007f Error: 287 201 core.c:1151 jtag_examine_chain(): double-check your JTAG setup (interface, speed, missing TAPs, ...) Unfortunately this is down to how the firmware in the adapter is written. Comms is limited to 64 byte USB packets, and the WRITE_READ command can therefore take a maximum of 488 bits (61 bytes after 3 header bytes). The 640 bit IDCODE scan is split up into 2 transactions, of which the first completes successfully. There is special-case code for 488-bit commands to hold TMS low on the last bit, so the TAP stays in DRSHIFT. Normally, TMS goes high for the last bit, to bring the TAP out to DREXIT1. Sadly though, the main loop of the adapter firmware adds a TMS=0, TDI=0 clock at the end of every WRITE_READ command. Under normal (entire command fits in 1 transaction) circumstances, this is to make the TAP transition from DREXIT1 to DRPAUSE. With split transactions, this extra clock loses a bit, and the returned data then makes no sense, leading to the "Unexpected idcode" messages above. I'm working on a solution, but have several options. a) Add yet more special case "if (bits == 488)" code in the adapter firmware main loop. This is horrible, but a quick fix. Would still go wrong if exactly 488 bits were required. b) Drop the extra clock from the adapter firmware, and add it in to the OpenOCD driver code. Good solution, but requires coordination of releases of both the adapter firmware and OpenOCD. c) Drop the existing limited adapter firmware in favour of a more capable protocol, not limited to 64 byte transfers, and understanding complete "do this entire scan" or "do this entire TMS sequence" commands. Even better, but quite some considerable work. Probably none of this (even a) will get done for 0.3.0, but if anyone has any thoughts, I'd be interested. -- Peter OpenOCD v0.2.0-452-gce88e8a ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] USBprog interface regression
On Sat, 11 Jul 2009, Øyvind Harboe wrote: There is one more thing that is unclear from what you have reported. Is this a problem with XScale or USBprog? It's definitely a problem with USBprog. What if your assumption false: USBprog could be working just fine w/short sequences today Give me some credit. I have read the code for both OpenOCD and the USBprog firmware (it is an open source adapter after all). I can assure you that the short sequences is the reason it's not working. Just let me know if you want me to extract and send you the bits of code to prove it. (I just happen to be testing it with an XScale target, because that's all I've got until my next toy-budget allocation allows me to buy some more dev boards! ;) -- Peter___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] USBprog interface regression
On Sat, 11 Jul 2009, Øyvind Harboe wrote: On Sat, Jul 11, 2009 at 10:24 AM, Peter Denison wrote: On Sat, 11 Jul 2009, Øyvind Harboe wrote: If I could return to the original point of this thread - getting the USBprog adapter to work at all - in the light of the other comments, are you going to let the one-line "make it work for now" fix in before 0.2? The downside to slipping in this fix is that it will be harder to retire the undocumented tms_sequence command and who's going to put in the work to fix it on the C side now? In return for putting the quick fix in, I will volunteer to step up to the plate for that. It will take some time though, because it will need to be coordinated with the USBprog firmware development. Also, I find it strange, but I'm not going to dive into USBprog, that it is possible to support pathmove, but not short sequences... Pathmove is done by sending the individual TMS and TCK line transitions. "Normal" state transitions are done by the TMS_CHAIN command, which does multiples of 7 bits. Now I'm fairly sure that the only reason USBprog did sets of 7 bits is because that was how OpenOCD originally did it internally, so the whole thing is ripe for improvement (along with other things such as abstracting runtest, and pushing that down as a single command, etc.). However, it will need careful interface versioning, and agreement from both sides. There is also plenty of scope for batching up commands as is done on other adapters. I will start the process of planning this with USBprog developers. -- Peter___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] USBprog interface regression
On Sat, 11 Jul 2009, Øyvind Harboe wrote: We need to move on with development and j-link is still being discussed actively. 0.2 is likely to be cut in the next 24-48 hours. We'll be releasing 0.3 soon after 0.2 anyway(a month or two), so this shouldn't be so bad. There are a handful of other problems for which there are workarounds that won't go into 0.2 also. OK. So J-Link will stay as it currently is until after 0.2.0. That's probably expedient to get the release out, and there will be people wanting to sort it out post-0.2.0 for a quick 0.3 release. That's good. If I could return to the original point of this thread - getting the USBprog adapter to work at all - in the light of the other comments, are you going to let the one-line "make it work for now" fix in before 0.2? -- Peter___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] USBprog interface regression
On Fri, 10 Jul 2009, Øyvind Harboe wrote: It's trivial in the sense that there's absolutely no way the adapter can work with the short transition table, Could you elaborate on this for those that read up on this thread later on? The USBprog adapter expects 7-bit sequences to be sent as part of its TMS_CHAIN command. More than one JTAG state transition from the table can be sent in a single USB command, but the adapter then treats each byte as a 7-bit TMS sequence to follow. Thus sending the shorter sequences from the short table results in the wrong transitions (e.g. IDLE -> DRSHIFT = B8(001, 3) is interpreted as 001, and 4 incorrect shifts of data out of DR are done and lost). By sticking to the old table (for this adapter only) with 7-bit transitions everywhere, this adapter that requires 7-bit transitions works. and some degree of getting it working with the original long one. I've added an item in TODO for this problem w/link to this thread. The patch will not be applied before 0.2 as there is a workaround. What workaround? Expecting anyone that uses it to work out that they need an extra line in their config file? At least we should make this adapter default to the correct table, so that no-one is caught out. I believe the fix for USBprog belongs inside the C code rather than in the config script. I agree, but I'd rather see 0.2.0 go out more likely to work out of the box than not... The C fixes are longer, more involved and you are right that they are inappropriate to happen before the release. It's a US Robotics USR8200 router, with an IXP422 processor. I can successfully bring it up into 'reset halt', and then can single step. I haven't tested the flash reading and writing yet, but will soon. I have USBprog and (temporarily) J-Link V6 adapters to compare. I don't know if J-Link will work for 0.2. If nothing drastic happens in the 24 hours, it won't make it. My J-Link V6 is working under debian squeeze as of SVN r2503, with my target. I appreciate that some of the other stuff recently discussed about the J-Link may not make it, but at least we can say "works under some circumstances, on some platforms". -- Peter___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] USBprog interface regression
On Fri, 10 Jul 2009, Øyvind Harboe wrote: This is not a trivial regression and I believe the XScale target code needs to be fixed. It's trivial in the sense that there's absolutely no way the adapter can work with the short transition table, and some degree of getting it working with the original long one. We should apply this anyway, and then go on to look at the other aspects. What XScale target are you testing against? It's a US Robotics USR8200 router, with an IXP422 processor. I can successfully bring it up into 'reset halt', and then can single step. I haven't tested the flash reading and writing yet, but will soon. I have USBprog and (temporarily) J-Link V6 adapters to compare. -- Peter___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] USBprog interface regression
I've recently had the opportunity to start testing the USBprog interface again. Since the introduction of the "short" tms transition table, the USBprog interface has been broken. The attached patch fixes it in one way, but I don't really like the fact that it can be undone from the command prompt. It also means we can't get rid of the long table any time soon. However, on the good side - my XScale target now works as well with this adapter as it does with J-Link! Please apply - it's trivial and fixes a regression. Index: tcl/interface/usbprog.cfg === --- tcl/interface/usbprog.cfg (revision 2503) +++ tcl/interface/usbprog.cfg (working copy) @@ -5,4 +5,5 @@ # interface usbprog +tms_sequence long ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] amtjtagaccel reports incorrect chip ID's
On Sat, 4 Jul 2009, Ferdinand Postema wrote:
> I understand that you do not want to make any changes so close to the
> release of a new version. No problem.
>
> I made 3 changes in the table amt_jtagaccel_tap_move. This table defines
> how to move from one state to the other. It consists of two bytes per
> state move. The five LSB of the first byte will be shifted out to the
> right to the TMS-line. If you need an other 5 bytes to reach the desired
> state, you have to OR the first word with 0x80 and supply the next 5
> bits in the second word (5 LSB).
>
> The first change is the neccesary one to correct the problem. This is
> the sequence to go from state RESET to state DRSHIFT. The value of these
> 2 bytes were 0x8a and 0x04. This means that the bitstream to do this
> transition is 0b 00100 01010 (send LSB first). This will bring you from
> the reset state to the shift state, but you enter the shift-state twice,
> which explains why the ID-CODE that will be read next is already shifted
> 1 bit. I corrected this to 0x05 and 0x00. This will send te bitstream
> 0b00101 (send LSB first). This will bring you from the RESET state to
> the DRSHIFT state more directly and without entering the DRSHIFT state
> twice.
>
> After checking the whole table, I found two other transitions that were
> correct, but could be optimized (5 bits in stead of 10 bits).
> Summary off all changes:
>From To Old values Old Bitstream New values New
> Bitstream Remark
> --- -- - --
> - --
>RESET DRSHIFT 0x8a 0x04 0b00100 01010 0x05 0x00
> 0b00101To Correct the error (and optimization)
>IDLE DRSHIFT 0x85 0x08 0b01000 00101 0x04 0x00 0b00100
> Optimization
>IDLE IRSHIFT 0x8b 0x08 0b01000 01011 0x06 0x00
> 0b00110Optimization
>
> Hopefully, this explanation helps.
Good explanation.
Duane Ellis wrote:
> (Forgive me, I have not followed your list of changes and so forth and I
> am entering the conversation late).
>
> One thing we *DO*NOT* want - is one "dongle" - (amt-jtagaccel) to act
> differently then some other tap because dongle (A) uses sequence (A),
> and another dongle (B) uses sequence (B) for the *exact*same*thing*.
>
> Please don't mis-understand 'fixing a bug is a correct and good thing'
> however optimizing things can introduce bugs.
The minimal change that fixes the bug is to just change the RESET to
DRSHIFT transition without optimising anything, just changing 0x8a, 0x04
to 0x8a, 0x08. That way the same state transitions are followed, and no
optimisation is done. At a later date, perhaps we could look at why this
adapter has its own jtag state table...
Index: src/jtag/amt_jtagaccel.c
===
--- src/jtag/amt_jtagaccel.c(revision 2461)
+++ src/jtag/amt_jtagaccel.c(working copy)
@@ -92,7 +92,7 @@
static uint8_t amt_jtagaccel_tap_move[6][6][2] =
{
/* RESET IDLEDRSHIFT DRPAUSE
IRSHIFT IRPAUSE */
- {{0x1f, 0x00}, {0x0f, 0x00}, {0x8a, 0x04}, {0x0a, 0x00}, {0x06, 0x00},
{0x96, 0x00}}, /* RESET */
+ {{0x1f, 0x00}, {0x0f, 0x00}, {0x8a, 0x08}, {0x0a, 0x00}, {0x06, 0x00},
{0x96, 0x00}}, /* RESET */
{{0x1f, 0x00}, {0x00, 0x00}, {0x85, 0x08}, {0x05, 0x00}, {0x8b, 0x08},
{0x0b, 0x00}}, /* IDLE */
{{0x1f, 0x00}, {0x0d, 0x00}, {0x00, 0x00}, {0x01, 0x00}, {0x8f, 0x09},
{0x8f, 0x01}}, /* DRSHIFT */
{{0x1f, 0x00}, {0x0c, 0x00}, {0x08, 0x00}, {0x00, 0x00}, {0x8f, 0x09},
{0x8f, 0x01}}, /* DRPAUSE */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cygwin & EOL settings - an idea..
On Tue, 9 Jun 2009, Duane Ellis wrote: > Could there be something we could put in the "configure script" - that > tells CYGWIN - to behave? > ie: Perhaps something like the SHELLOPTS thing? > > For example - maybe in the "bootstrap" script? > And in the "CONFIGURE' script? > And in the Makefiles? > > FYI - with SVN - is who thinks what is native and when. > > Tortiose - Native = Windows, period, no way to override this > SVN - cygwin = Native = CYGWIN setting >SVN - DOS = Native = Windows >SVN - on a Linux box = Unix > It's even more nasty, if you share something via SAMBA... Maybe I'm missing something subtle, but as I understand it, the problem is that a shell script (which will never be attempted to be run by native Windows) is sometimes failing because it has CRLF "Windows" line-endings. Why don't we set the svn:eol-style property on that file to be LF? That way, it will always get LF and only LF line endings, regardless of the system on which it is checked out. svn propset svn:eol-style 'LF' guess-rev.sh (and all other .sh files) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [COMMIT] jlink 8bit TLR patch
On Tue, 2 Jun 2009, Spencer Oliver wrote: > I have committed the attached patch to svn. > > - hack added to fix a issue with v5/6 jlink > v5/6 jlink seems to have an issue if the first tap move is not divisible by > 8, so we send a TLR on first power up > > Cheers > Spen Much better than my hack, however... In communication with Rolf Segger, who helpfully contacted me, I've established that newer firmware (dated May 27 2009 17:26:00) does not need the special case of multiples of 8 clocks as its first transaction. My old firmware (Mar 3 2008 18:04:42) requires the mulitple-of-8 clocks. I don't know how many versions in between are out "in the wild", and which ones do or don't require the fix. The question is, should we leave it in, or detect an older firmware and actively suggest an upgrade? The Linux update utility doesn't work - you have to do it in Windows. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Ugly fix for J-Link hard power-on
Some (all?) V6 firmware on the J-Link adapter fails to step the TAP unless
the first EMU_CMD_HW_JTAG3 command has 8 bits rather than 7, immediately
after adapter power-up. Add a hack to pad out to 8 bits, the first time
only.
Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c (revision 1932)
+++ src/jtag/jlink.c (working copy)
@@ -692,6 +692,9 @@
static int pending_scan_results_length;
static pending_scan_result_t pending_scan_results_buffer[MAX_PENDING_SCAN_RESULTS];
+static int last_tms;
+static int first_time = 1;
+
static void jlink_tap_init(void)
{
tap_length = 0;
@@ -711,6 +714,7 @@
static void jlink_tap_append_step(int tms, int tdi)
{
+ last_tms = tms;
int index = tap_length / 8;
if (index >= JLINK_TAP_BUFFER_SIZE)
@@ -780,6 +784,19 @@
jlink_tap_append_step((tap_get_state() == TAP_RESET)?1:0, 0);
}
+ /* The first time we do a TAP move, pad last byte so that tap_length
+ * is divisible by 8. This is necessary for some V6 versions after a
+ * hard power-up. */
+ if (first_time) {
+ while (tap_length % 8 != 0)
+ {
+ /* More of the last TMS value keeps us in the same
+ * state, analogous to free-running JTAG interfaces. */
+ jlink_tap_append_step(last_tms, 0);
+ }
+ first_time = 0;
+ }
+
// number of full bytes (plus one if some would be left over)
byte_length = TAP_SCAN_BYTES(tap_length);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Sat, 30 May 2009, Peter Denison wrote: > On Sat, 30 May 2009, Magnus Lundin wrote: > >> It looks like you are using jtag_khz 0, this means adaptive clocking with >> the RTCK signal. This work for LPC3148 that has a RTCK signal, but as far as >> I can find there is no RTCK singal on the TMS470R1A256. >> >> For testing interface problem I would suggest, always start with a slow jtag >> clock, like jtag_khz 30 or 100. If this works try to increase it. > > Many thanks! Somehow in my testing (probably to try to replicate XC's > config) I had put jtag_rclk in my .cfg file. > > I've replaced it with jtag_khz 30, and I can at least initialise now. > Sorry for the misdirection. > > So, summary: r1932, J-Link V6, XScale IXP422 target. Initialisation works. Only it doesn't reliably! This adapter is driving me up the wall. The first time after power-up, the adapter fails on the first EMU_CMD_HW_JTAG3 if it's 7 bits (0x7F) long, and works if it's 8 bits (0xFF) long. By failure, I mean that the adapter simply fails to respond to the command, and the USB layer times out. However, after it has worked once, any size bit sequences work. I suppose I could put in a "first time" flag so that the first (RESET -> RESET) transition is always 8 bits. Thoughts? J-Link ARM V6 compiled Mar 3 2008 18:04:42 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Minor fix to J-Link debugging
The debugging code in jlink_tap_execute() called when _DEBUG_USB_COMMS_ is
defined was using the entire cached scan length to print the results
buffers, and not the correct length of each individual buffer.
Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c (revision 1932)
+++ src/jtag/jlink.c (working copy)
@@ -818,7 +818,7 @@
DEBUG_JTAG_IO("pending scan result, length = %d", length);
#ifdef _DEBUG_USB_COMMS_
- jlink_debug_buffer(buffer, byte_length);
+ jlink_debug_buffer(buffer, TAP_SCAN_BYTES(length));
#endif
if (jtag_read_buffer(buffer, command) != ERROR_OK)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dealing with cumulative patches - and patch sets
On Sat, 30 May 2009, Duane Ellis wrote: > All, > (especially david & zach, you seem to do this very well). > > Yes, this is some what "off-topic" for this list, but it is on topic > because the list wants "small more reviewable patches". To that end, I'm > looking for a better way to deal with patch sets, etc. > > I've noticed that for example some post a nice series of 10 patches... > each a minor step... in total quite a lot, and the poster tends to do > all of these patches at once. > > Problem #1. > > > Yea, I can create an SVN patch - from HEAD, but that's not what I'm > looking for. For example - if I have 5 changes to a file, and they are > standalone patches, I do the work 'independently' - ie: change 1 today, > change 2 tomorrow, etc. > > Other then manually editing the resulting "cumulative patch" (a nasty > job) - what better way or tool is there to do this? Quilt. It's exactly the tool to do this. > Problem #2 > > > So those patches are posted... on the list, waiting for stuff, and I > have other things to deal with. Creating the next patch, for a > different file - or set of files is again painfully manual. > > Isn't there some way to say: "Hey patch tool - you already know about > those first 5 changes in Problem #1" please ... assume those are done, > and create my patch file based on that. > > How can I do that? Again, other then manually editing the patch file, or > manually creating crazy command lines to do the diffs/patch generation. Quilt again. http://linux.die.net/man/1/quilt for the man page (without installing it). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Sat, 30 May 2009, Magnus Lundin wrote: > Xiaofan Chen wrote: >> On Sat, May 30, 2009 at 1:01 AM, Peter Denison >> wrote: >> >>> Unfortunately not mine... I still get a 1 returned (instead of a zero) as >>> the error code from EMU_CMD_HW_JTAG3, when I send 8 bits: >>> >>> Debug: 192 667 jlink.c:1095 jlink_debug_buffer(): cf 00 08 00 ff 00 >>> Debug: 194 694 jlink.c:1095 jlink_debug_buffer(): 00 >>> Debug: 196 695 jlink.c:1095 jlink_debug_buffer(): 01 >>> >> >> I got similar problem with r1948 and r1508 for the TMS470R1A256 target >> even though r1508 is supposed to work because of sending 8bits. >> >> And I have no problems with r1948 for the Olimex LPC-P2148. >> >> So it seems to me the target may play a part as well. > It looks like you are using jtag_khz 0, this means adaptive clocking with > the RTCK signal. This work for LPC3148 that has a RTCK signal, but as far as > I can find there is no RTCK singal on the TMS470R1A256. > > For testing interface problem I would suggest, always start with a slow jtag > clock, like jtag_khz 30 or 100. If this works try to increase it. Many thanks! Somehow in my testing (probably to try to replicate XC's config) I had put jtag_rclk in my .cfg file. I've replaced it with jtag_khz 30, and I can at least initialise now. Sorry for the misdirection. So, summary: r1932, J-Link V6, XScale IXP422 target. Initialisation works. Now the tcl scripts have moved, I need to work out how to be in the right directory (src/target) to find the XScale debug handler, and the right directory (tcl) for "source [find target/ixp42x.cfg]" to work... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Fri, 29 May 2009, Spencer Oliver wrote: >>> Still it would be very good to know if this is the problem for (at >>> least some of) the V6 adapters. >> >> Unfortunately not mine... I still get a 1 returned (instead >> of a zero) as the error code from EMU_CMD_HW_JTAG3, when I >> send 8 bits: >> >> Debug: 191 667 jlink.c:1032 jlink_usb_write(): >> jlink_usb_write, out_length = 6, result = 6 >> Debug: 192 667 jlink.c:1095 jlink_debug_buffer(): cf 00 >> 08 00 ff 00 >> Debug: 193 694 jlink.c:1054 jlink_usb_read(): jlink_usb_read, >> result = 1 >> Debug: 194 694 jlink.c:1095 jlink_debug_buffer(): 00 >> Debug: 195 695 jlink.c:1069 jlink_usb_read_emu_result(): >> jlink_usb_read_result, result = 1 >> Debug: 196 695 jlink.c:1095 jlink_debug_buffer(): 01 >> Error: 197 695 jlink.c:971 jlink_usb_message(): >> jlink_usb_message failed with result=1) >> Error: 198 695 jlink.c:810 jlink_tap_execute(): >> jlink_tap_execute, wrong result -107 (expected 1) >> >> This is both from a power-up, and from warm (though not >> testing with an earlier "working" version). >> > > what jlink firmware version is this? > mine reports: > J-Link ARM V6 compiled Nov 5 2008 20:49:58 J-Link ARM V6 compiled Mar 3 2008 18:04:42 I don't think much of their revision control, to be honest. The capabilities of a lot of the versions we see in traces are wildly different, and the only distinction is a date. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Fri, 29 May 2009, Magnus Lundin wrote: >> I have attached logs of both rev, as you can see the line of interest for >> r1508 is >> Debug: 119 218 jlink.c:963 jlink_debug_buffer(): cf 00 08 00 ff 00 >> and r1509 >> Debug: 119 249 jlink.c:963 jlink_debug_buffer(): cf 00 07 00 7f 00 >> > Yes, it definetly seems some JLinks dislikes 7 bit transactions, but not > always, not if they are in a good mode after running rev 1188. > > We can patch all transactions to be a multiple of 8, but that has a > tendency of driving some arm7/9 targets into a strange state if the > endstate is IDLE, since this is the clock instruction into cpu. For > Cortex targets this is not a problem. > > Still it would be very good to know if this is the problem for (at least > some of) the V6 adapters. Unfortunately not mine... I still get a 1 returned (instead of a zero) as the error code from EMU_CMD_HW_JTAG3, when I send 8 bits: Debug: 191 667 jlink.c:1032 jlink_usb_write(): jlink_usb_write, out_length = 6, result = 6 Debug: 192 667 jlink.c:1095 jlink_debug_buffer(): cf 00 08 00 ff 00 Debug: 193 694 jlink.c:1054 jlink_usb_read(): jlink_usb_read, result = 1 Debug: 194 694 jlink.c:1095 jlink_debug_buffer(): 00 Debug: 195 695 jlink.c:1069 jlink_usb_read_emu_result(): jlink_usb_read_result, result = 1 Debug: 196 695 jlink.c:1095 jlink_debug_buffer(): 01 Error: 197 695 jlink.c:971 jlink_usb_message(): jlink_usb_message failed with result=1) Error: 198 695 jlink.c:810 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) This is both from a power-up, and from warm (though not testing with an earlier "working" version). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Fri, 29 May 2009, Spencer Oliver wrote:
>> Spencer Oliver wrote:
> The strange thing is if i then connect using r1943 it will work !!
> Replug the jlink and it will fail with r1943, run r1192
> then all is ok again.
>>>
>>> Tracing further in.
>>> For me the break is @ r1509 (tms pad patch) - now to find a
>> solution.
> a bit more debugging
> The issue seesms to be in the function jlink_tap_execute
>
> the change in r1509 that causes the issue is:
> // number of full bytes (plus one if some would be left over)
> byte_length = tap_length / 8 + !!(tap_length % 8);
>
> instead of r1508
>
> /* Pad last byte so that tap_length is divisible by 8 */
> while (tap_length % 8 != 0)
> {
> /* More of the last TMS value keeps us in the same state,
>* analogous to free-running JTAG interfaces. */
> jlink_tap_append_step(last_tms, 0);
> }
> byte_length = tap_length / 8;
>
> I have attached logs of both rev, as you can see the line of interest for
> r1508 is
> Debug: 119 218 jlink.c:963 jlink_debug_buffer(): cf 00 08 00 ff 00
> and r1509
> Debug: 119 249 jlink.c:963 jlink_debug_buffer(): cf 00 07 00 7f 00
Well found, although it doesn't explain why it should work with >=r1509
after having previously worked with <=r1508.
Apologies for my misdirection about r1498. I saw large changes to the
testing code under svn blame, but they were merely refactoring, and
weren't substantive.
It also concerns me that padding with the last TMS is considered to be
universally OK. When you move to DR_SHIFT, there are side-effects
(starting to clock the value out!) if you introduce extra clocks.
Particularly with the XScale, it needs to be taken to DR_SHIFT via
pathmove(), and if anything introduces extra clocks after that, the data
will start to be clocked out.
I will try this change in isolation, and report back.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TMS470 Scripts
On Wed, 27 May 2009, Xiaofan Chen wrote: > Thanks a lot for the help. I could not connect the TMS470R1A256 IAR > Starter Kit properly to J-Link with the script. I have not used your patch > yet as it seems more for the debugging part. I want to connect and then > reset/halt first. > > > mc...@ubuntu904:~/Desktop/build/openocd/tms470$ openocd -f tms470r1a256.cfg > Open On-Chip Debugger 0.2.0-in-development (2009-05-25-21:15) svn:1910 > > BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS > > $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ > Error: J-Link command EMU_CMD_VERSION failed (-110) > > Error: J-Link command EMU_CMD_VERSION impossible return length 0x2d4a > Error: J-Link command EMU_CMD_VERSION failed (-110) > > Info : J-Link ARM V6 compiled Apr 1 2009 11:56:10 > Info : JLink caps 0x19ff7bbf > Info : JLink hw version 6 > Info : JLink max mem block 8376 > Info : Vref = 3.132 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1 > > Info : J-Link JTAG Interface ready > Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive > packet not sent! (6118). Workaround: increase "set remotetimeout" in > GDB > Error: jlink_usb_message failed with result=1) > Error: jlink_tap_execute, wrong result -107 (expected 1) I get this repeated result as well, with a Yellow V6 J-Link, and a USR8200 (IXP422) target board: --8< Open On-Chip Debugger 0.2.0-in-development (2009-05-27-19:22) svn:1932M BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ RCLK - adaptive Error: J-Link command EMU_CMD_VERSION failed (-110) Error: J-Link command EMU_CMD_VERSION impossible return length 0x2d4a Error: J-Link command EMU_CMD_VERSION failed (-110) Info : J-Link ARM V6 compiled Mar 3 2008 18:04:42 Info : JLink caps 0x1f7fbf Info : JLink hw version 6 Info : JLink max mem block 9992 Info : Vref = 3.313 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 1 Info : J-Link JTAG Interface ready Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (6211). Workaround: increase "set remotetimeout" in GDB Error: jlink_usb_message failed with result=1) Error: jlink_tap_execute, wrong result -107 (expected 1) 8<-- The offending lines that cause it to break were added in jlink.c by Oyvind in r1498. However, according to the docs (RM08001-02, dated June 30, 2008 at www.segger.com), they should be correct. Once you've read the TDO lines out, read the next byte out, and if it's 0, it's OK, if not, it's an error. Sadly, the docs don't go on to explain what an error code of 1 means. Mine is consistently reading out a 1 instead of a 0. As an aside, the new 'jlink hw jtag' command is a good idea, but the hardware version read from the adapter always overrides any command line value you've put in. I'm seriously considering ditching the J-Link, and going back to trying to get the USBprog to be a fully featured JTAG adapter. It's more work, but at least both ends are open source. (Twice as many communities to interact with - yay ;) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
On Wed, 27 May 2009, Xiaofan Chen wrote:
> On Wed, May 27, 2009 at 2:29 AM, Peter Denison wrote:
>> On Mon, 25 May 2009, Xiaofan Chen wrote:
>>> I do not think so. From the website, it does not
>>> even program AVR32 properly as of now.
>>
>> It does. The website is woefully out of date. I have used a USBprog to
>> program AVR32s, using avrdude, and it is also fully recognised by
>> AVR32Studio, when programmed correctly.
>>
>
> Does avrdude support AVR32? I do not know that. Thanks for the
> information. I am not familiar with AVR32.
My mistake - I can only confirm (from experience) that it programs
AtMega32 devices.
The man page for avrdude says that it will program AT90,
ATmega{8,16,32,48,64,128,256} and ATtiny parts.
I still think that USBprog supports the full JTAGICE protocol though.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
On Mon, 25 May 2009, Xiaofan Chen wrote: > 2009/5/25 SimonQian : >> For supporting AVR32 debugging under IAR EWAVR32 and >> AVR32Studio, you MUST emulate JTAGICE mkII. > > I see. Thanks. USBprog does do full JTAGICEmkII emulation, I believe - I haven't tested it myself doing debugging, but I think it's all there >> Does USBprog support AVR32 debugging? >> > I do not think so. From the website, it does not > even program AVR32 properly as of now. It does. The website is woefully out of date. I have used a USBprog to program AVR32s, using avrdude, and it is also fully recognised by AVR32Studio, when programmed correctly. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
On Mon, 18 May 2009, Peter Denison wrote: > On Mon, 18 May 2009, Peter Denison wrote: > >> Now, on to the actual crash. I will do more investigation, but for now, >> here's the backtrace: >> >> Starting program: /src/.libs/lt-openocd -f >> ../../../openocd-usr8200-jlink.cfg >> Open On-Chip Debugger 0.2.0-in-development (2009-05-18-18:52) svn:1827M >> >> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS >> >> $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ >> jtag_speed: 16 >> Error: J-Link command EMU_CMD_VERSION failed (-110) >> >> Error: J-Link command EMU_CMD_VERSION failed (-110) >> >> Program received signal SIGSEGV, Segmentation fault. >> jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940 >> 940 result = usb_bulk_write_ex(jlink_jtag->usb_handle, >> JLINK_WRITE_ENDPOINT, >> (gdb) bt >> #0 jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940 >> #1 0xb7feaaf8 in jlink_simple_command (command=1 '\001') at jlink.c:509 >> #2 0xb7febbb0 in jlink_get_version_info () at jlink.c:549 >> #3 0xb7febf2d in jlink_init () at jlink.c:324 >> #4 0xb7fe2bbf in jtag_interface_init (cmd_ctx=0x804a008) at jtag.c:2333 > > Preliminary look at this seems to be that jlink_jtag_handle is overwritten > with junk. This sits in memory directly after usb_emu_result_buffer, which > is 64 bytes long. Are any of the new in_handler replacement callbacks > overwriting the end of this buffer? Sorry - that was a wild guess, and was totally wrong. It seems that the interface (I have the yellow J-Link V6) can get into an odd state where it responds incorrectly to an EMU_CMD_VERSION command (0x01). In this state, it replies with the string "J-Link ARM V6 compiled Mar 3 2008 18:04:42" immediately, without sending the 0x0070 length field first. I have confirmed this with the kernel-level USB trace provided by usbmon. The result is that the first two characters get interpreted as a length, "J-" = 0x4a 0x2d => 0x2d4a = 11594, much larger than the 2048 bytes allocated for the USB input buffer. With the changes introduced in r1475, where the expected length is passed to the bulk read function, this will now time out and/or overwrite usb_read_buffer. In jlink_usb_read() we should definitely check that the expected size is not larger than the buffer. That will catch the segfault. What the correct course of action after that is, I don't know. Put in an explicit check for length == 0x2d4a, and emit a message suggesting an adapter power-cycle? I'm open to suggestions. I'll see if I can produce a workable patch... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
On Mon, 18 May 2009, Peter Denison wrote: > Now, on to the actual crash. I will do more investigation, but for now, > here's the backtrace: > > Starting program: /src/.libs/lt-openocd -f > ../../../openocd-usr8200-jlink.cfg > Open On-Chip Debugger 0.2.0-in-development (2009-05-18-18:52) svn:1827M > > BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS > > $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ > jtag_speed: 16 > Error: J-Link command EMU_CMD_VERSION failed (-110) > > Error: J-Link command EMU_CMD_VERSION failed (-110) > > > Program received signal SIGSEGV, Segmentation fault. > jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940 > 940 result = usb_bulk_write_ex(jlink_jtag->usb_handle, > JLINK_WRITE_ENDPOINT, > (gdb) bt > #0 jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940 > #1 0xb7feaaf8 in jlink_simple_command (command=1 '\001') at jlink.c:509 > #2 0xb7febbb0 in jlink_get_version_info () at jlink.c:549 > #3 0xb7febf2d in jlink_init () at jlink.c:324 > #4 0xb7fe2bbf in jtag_interface_init (cmd_ctx=0x804a008) at jtag.c:2333 Preliminary look at this seems to be that jlink_jtag_handle is overwritten with junk. This sits in memory directly after usb_emu_result_buffer, which is 64 bytes long. Are any of the new in_handler replacement callbacks overwriting the end of this buffer? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
On Mon, 18 May 2009, Øyvind Harboe wrote:
Try using
libtool gdb ../openocd
or the more pedantic (but future-proof):
libtool --mode=execute gdb ../openocd
Once a solution has been identified, it would be nice to have the BUGS
file updated...
Excellent! That (to be precise the second of the two) worked.
It would be nice to have the BUGS file updated.
Now, on to the actual crash. I will do more investigation, but for now,
here's the backtrace:
Starting program: /src/.libs/lt-openocd -f
../../../openocd-usr8200-jlink.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05-18-18:52) svn:1827M
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
jtag_speed: 16
Error: J-Link command EMU_CMD_VERSION failed (-110)
Error: J-Link command EMU_CMD_VERSION failed (-110)
Program received signal SIGSEGV, Segmentation fault.
jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940
940 result = usb_bulk_write_ex(jlink_jtag->usb_handle,
JLINK_WRITE_ENDPOINT,
(gdb) bt
#0 jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940
#1 0xb7feaaf8 in jlink_simple_command (command=1 '\001') at jlink.c:509
#2 0xb7febbb0 in jlink_get_version_info () at jlink.c:549
#3 0xb7febf2d in jlink_init () at jlink.c:324
#4 0xb7fe2bbf in jtag_interface_init (cmd_ctx=0x804a008) at jtag.c:2333
#5 0xb7fdc456 in handle_init_command (cmd_ctx=0x804a008,
cmd=0x8057f30 "init", args=0x806b3bc, argc=0) at openocd.c:133
#6 0xb8085dca in run_command (context=0x804a008, c=0x8057f50,
words=0x806b3b8, num_words=1) at command.c:399
#7 0xb8086105 in script_command (interp=0x804a020, argc=1, argv=0xbf8e58e0)
at command.c:126
#8 0xb8076a9a in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x806b1e8)
at jim.c:8708
#9 0xb807dfff in Jim_EvalCoreCommand (interp=0x804a020, argc=3,
argv=0xbf8e59b0) at jim.c:10846
#10 0xb8076a9a in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x806a260)
at jim.c:8708
#11 0xb807c7af in Jim_CatchCoreCommand (interp=0x804a020, argc=2,
argv=0xbf8e5a80) at jim.c:11413
#12 0xb8076a9a in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x806a488)
at jim.c:8708
#13 0xb8078361 in Jim_EvalExpression (interp=0x804a020, exprObjPtr=0x806a5e0,
exprResultPtrPtr=0xbf8e5c04) at jim.c:6927
#14 0xb80791a8 in Jim_GetBoolFromExpr (interp=0x804a020, exprObjPtr=0x806a5e0,
boolPtr=0xbf8e5c58) at jim.c:7210
#15 0xb807f975 in Jim_IfCoreCommand (interp=0x804a020, argc=5, argv=0xbf8e5cd0)
at jim.c:10297
#16 0xb8076a9a in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x8058728)
at jim.c:8708
#17 0xb80771e1 in JimCallProcedure (interp=0x804a020, cmd=0x80588d0, argc=0,
argv=0xbf8e5de0) at jim.c:8857
#18 0xb8076e62 in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x8059960)
at jim.c:8714
#19 0xb80819cc in Jim_EvalFile (interp=0x804a020,
filename=0x8059938 "../../../openocd-usr8200-jlink.cfg") at jim.c:8992
#20 0xb8082205 in Jim_SourceCoreCommand (interp=0x804a020, argc=2,
argv=0xbf8e5ef0) at jim.c:12034
#21 0xb8076a9a in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x80512f8)
at jim.c:8708
#22 0xb80771e1 in JimCallProcedure (interp=0x804a020, cmd=0x8055ee8, argc=2,
argv=0xbf8e6000) at jim.c:8857
#23 0xb8076e62 in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x80586a8)
at jim.c:8714
#24 0xb8077da1 in Jim_Eval_Named (interp=0x804a020,
script=0x80582c8 "script {../../../openocd-usr8200-jlink.cfg}",
filename=0xb80a64af "command.c", lineno=453) at jim.c:8901
#25 0xb8085cc6 in command_run_line (context=0x804a008,
line=0x80582c8 "script {../../../openocd-usr8200-jlink.cfg}")
at command.c:453
#26 0xb808452d in parse_config_file (cmd_ctx=0x804a008) at configuration.c:118
#27 0xb7fdc368 in openocd_main (argc=3, argv=0xbf8e62c4) at openocd.c:268
#28 0x080484f2 in main (argc=136, argv=0x68) at main.c:39___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
On Mon, 18 May 2009, Øyvind Harboe wrote: $ gdb ../openocd --args openocd ... ends up running /usr/bin/openocd ... Try gdb --args openocd -f interface/xxx.cfg -f target/.cfg ... This runs the one (r1409) in /usr/bin, not my newly compiled one. If I find the actual executable, which I think is in src/.libs/openocd, and try to tell gdb to run that, I get: $ gdb ../.libs/openocd (gdb) set args -f ../../../openocd-usr8200-jlink.cfg (gdb) run Starting program: /src/.libs/openocd -f ../../../openocd-usr8200-jlink.cfg /src/.libs/openocd: error while loading shared libraries: libopenocd.so.0: cannot open shared object file: No such file or directory Program exited with code 0177. (gdb) Any attempt to pass --args openocd results in the installed /usr/bin/openocd being run in the debugger, and not my compiled version. => The move to "libify" openocd has broken some use-cases I wasn't going to get embroiled in the development discussions, because active work is good for open source projects, but I wish the breaking work had been done in a branch so that others could carry on. My (limited) contributions have been delayed by spending time just getting my environment working again.___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
On Mon, 18 May 2009, Øyvind Harboe wrote: [Oops - failed to copy the original to the list...] On Mon, May 18, 2009 at 8:21 AM, Peter Denison wrote: On Sat, 16 May 2009, Øyvind Harboe wrote: Could you post a GDB backtrace? See: http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS I tried to do that, but since the changes for "librification" of openocd, it doesn't work, as src/openocd is no longer an executable, but is a script. I haven't yet worked out how to successfully run gdb on it. I used gdb --args openocd Still works here Grateful if you (or Zach) could let me know how to run gdb, then I will happily provide a backtrace. Please provide any extra detail you might have, because we obviously need this to work and it does work on Cygwin at least... OK. System: debian squeeze (libtool 2.2.6a, autoconf 2.63, automake 1:1.10.2) Revision: 1827 Built: ./bootstrap; ./configure --enable-jlink --enable-usbprog --enable-maintainer-mode --enable-verbose; make $ cd src/target $ gdb ../openocd GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... "/src/openocd": not in executable format: File format not recognized $ $ gdb ../openocd --args openocd ... ends up running /usr/bin/openocd ... which is the debian-installed version, at r1409 and not the program I want to debug. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
On Sat, 9 May 2009, Øyvind Harboe wrote: Please report any problems you are experiencing with svn head. Except for the performance regressions, which will be addressed next week, there are no reported problems at this point w.r.t. the JTAG API changes. Every *other* time I run, I get this... --8<- Open On-Chip Debugger 0.2.0-in-development (2009-05-16-19:44) svn:1799M BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ jtag_speed: 16 Error: J-Link command EMU_CMD_VERSION failed (-110) Segmentation fault --8<- alternating with this: --8<- Open On-Chip Debugger 0.2.0-in-development (2009-05-16-19:44) svn:1799M BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ jtag_speed: 16 Error: J-Link command EMU_CMD_VERSION failed (-110) Info : J-Link ARM V6 compiled Mar 3 2008 18:04:42 Info : JLink caps 0x1f7fbf Info : JLink max mem block 9992 Info : Vref = 3.280 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 1 Info : J-Link JTAG Interface ready Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3195). Workaround: increase "set remotetimeout" in GDB Info : JTAG tap: ixp42x.cpu tap/device found: 0x19277013 (Manufacturer: 0x009, Part: 0x9277, Version: 0x1) Info : JTAG Tap/device matched Warn : no tcl port specified, using default port Info : JTAG tap: ixp42x.cpu tap/device found: 0x19277013 (Manufacturer: 0x009, Part: 0x9277, Version: 0x1) Info : JTAG Tap/device matched Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1954). Workaround: increase "set remotetimeout" in GDB Error: invalid mode value encountered Error: cpsr contains invalid mode value - communication failure Error: timed out while waiting for target halted Runtime error, file "embedded:startup.tcl", line 211: expected return code but got 'TARGET: ixp42x.cpu - Not halted' Runtime error, file "../../../openocd-usr8200-jlink.cfg", line 49: --8<- This setup has worked (at least more than it does at present - I could read registers, etc), but I don't have the information as to which SVN version did work, sorry. My only mod is to another adapter, so don't worry about the 'M'!! I will continue debugging, and will provide more information later...___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink + MC1322x
On Fri, 13 Mar 2009, Rick Altherr wrote: > On Mar 13, 2009, at 2:47 PM, Peter Denison wrote: >> There are also adapters (at least one - USBprog) that rely on the fact that >> there are exactly 7 state transitions in every tms sequence. This is not >> immutable, but it will need coordination and will have to change if OpenOCD >> does. > > Does the adapter actually depend on the 7 state transitions or does the > driver for that adapter in OpenOCD rely on that. If the former, we have a > problem. If the latter, it just means we need to be sure to update the > driver. As far as I have been able to discern, every single adapter OpenOCD > supports is just fed a stream of bytes indicating the pin states for the next > cycle. The USBprog adapter firmware depends on doing things in 7-cycle groups. However, it is open-source firmware, so we can change it, but it will just need a load more coordination. >From what you've said, it sounds like it's the only one that is like that. I strongly suspect that the adapter firmware was written with detailed internal knowledge of OpenOCD, and that at that stage 7 clocks for each transition fitted nicely. P.S. Any chance of looking at the USBprog/JLink patch, at https://lists.berlios.de/pipermail/openocd-development/2009-March/004957.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink + MC1322x
On Fri, 13 Mar 2009, Jeff Williams wrote: El Mar 13, 2009, a las 04:30 , Duane Ellis escribió: 2) jtag/jtag.h. changing state numbers concerns me - but i see *exactly* why you are doing this. Perhaps this sort of stuff would have helped earlier with the beagle board work. And it looks like a good idea. I'd like others to comment also. (*HEY* anybody else reading this?*) ie: ?DIRK/DICK? I forget who - wrote quite a bit of stuff with an SVF playback code to do xilinx stuff. I'd hate to break that... This is a big factor in the JLink working correctly, because it seems the MC1322x has a low tolerance for anything not following the letter of the official spec. I'm not an ARM or JTag expert (yet) but I chalk this narrow window to being normal for a new part. I have very serious doubts about this *as it stands* (meaning only that I want more discussion - I'm not trying to close it down!). Several of the transitions in there are not correct, particularly the DRSHIFT->DRSHIFT, and IRSHIFT->IRSHIFT. Yes, a single clock with TMS = 0 will cause the TAP to stay in xxSHIFT, but it will also clock a bit out of the register, which is not what we want when doing TAP movement. There is a note somewhere (I think above the original version of the table) that says it's the adapter code's job to catch xxSHIFT->xxSHIFT transitions and treat them differently, but we shouldn't do the wrong thing anyway. I have recently posted a patch to fix one of the problems on the JLink adapter, related to DRSHIFT->DRSHIFT transitions. (likewise I sometimes wonder if anyone is reading this ;) There are also adapters (at least one - USBprog) that rely on the fact that there are exactly 7 state transitions in every tms sequence. This is not immutable, but it will need coordination and will have to change if OpenOCD does. 3) the state numbers - could you put a better reference in. Example: The state numbers are from: Document: ARM 7TDMI Technical Reference Manual Revision: R4P1 Section: B.1.2 Arm Document ID Number: DDI 0210C Good point. Agreed. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Partially fix USBprog and JLink adapters on XScale target
The XScale target uses JTAG_PATHMOVE to get the TAP to the DRSHIFT state.
This patch fixes subsequent scans on the USBprog and J-Link adapters, so
that they don't try to make another transition (7 clocks) to DRSHIFT.
It also fixes the USBprog adapter to flush any pending TAP moves before
doing 'manual' state stepping during usbprog_path_move().Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c(revision 1383)
+++ src/jtag/jlink.c(working copy)
@@ -424,7 +424,10 @@
/* Move to appropriate scan state */
jlink_end_state(ir_scan ? TAP_IRSHIFT : TAP_DRSHIFT);
- jlink_state_move();
+ /* Only move if we're not already there */
+ if (tap_get_state() != tap_get_end_state())
+ jlink_state_move();
+
jlink_end_state(saved_end_state);
/* Scan */
Index: src/jtag/usbprog.c
===
--- src/jtag/usbprog.c (revision 1383)
+++ src/jtag/usbprog.c (working copy)
@@ -265,6 +265,10 @@
int num_states = cmd->num_states;
int state_count;
+ /* There may be queued transitions, and before following a specified
+ path, we must flush those queued transitions */
+ usbprog_jtag_tms_send(usbprog_jtag_handle);
+
state_count = 0;
while (num_states)
{
@@ -323,6 +327,10 @@
usbprog_write(0, 0, 0);
}
+#ifdef _DEBUG_JTAG_IO_
+ LOG_DEBUG("runtest: cur_state %s end_state %s",
tap_state_name(tap_get_state()), tap_state_name(tap_get_end_state()));
+#endif
+
/* finish in end_state */
/*
usbprog_end_state(saved_end_state);
@@ -340,9 +348,10 @@
else
usbprog_end_state(TAP_DRSHIFT);
- /* usbprog_jtag_tms_send(usbprog_jtag_handle); */
+ /* Only move if we're not already there */
+ if (tap_get_state() != tap_get_end_state())
+ usbprog_state_move();
- usbprog_state_move();
usbprog_end_state(saved_end_state);
usbprog_jtag_tms_send(usbprog_jtag_handle);
@@ -360,6 +369,7 @@
usbprog_jtag_write_and_read(usbprog_jtag_handle,buffer,
scan_size);
}
+ /* The adapter does the transition to PAUSE internally */
if (ir_scan)
tap_set_state(TAP_IRPAUSE);
else
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] BeagleBoard - OMAP - & DRSCAN and IRSCAN issues
On Sun, 8 Mar 2009, Dirk Behme wrote: > The main issue I see which needs to be addressed before is the "do > always 7 clocks from one TAP state to an other" OpenOCD uses at the moment > > https://lists.berlios.de/pipermail/openocd-development/2009-February/004625.html Please be aware that if you are changing the assumption that 7 clocks are always made for a transition, that there are adapters and support code that rely on that fact. (e.g. USBprog) You may be right in what you are proposing, but make sure you follow up with all the adapters! (please?) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] TAP state transitions (Was Re: Further XScale target issues and adapter comparisons)
On Sat, 7 Mar 2009, Peter Denison wrote:
> This write to DCSR should then let the target run (the debug code just
> loaded into the cache), and then the next read is from TX, which the
> debug handler should have written to. However, the 3 guard bits in
> fields[0].in_value[3] should be 010 or 011 (from the hardware), and they
> aren't, which is why I think it's an extra bit clocked somewhere.
I've been looking more closely at the TAP state transtition table in
src/jtag/jtag.c, in tap_get_tms_path(), and first of all there are some
assumptions I must query:
1) Should a transition from one {DR,IR}SHIFT or {DR,IR}PAUSE to another
always make the transtion through {DR,IR}CAPTURE?
Currently some do and some don't
2) Should a transition into {DR,IR}SHIFT always guarantee to arrive at
that state on the last clock of the fixed 7?
Currently most do, but some don't.
3) At the end of a known number of bits in {DR,IR}SHIFT, are the adapter
codes expected to exit into {DR,IR}EXIT1, or to stay in SHIFT? This
assumption is crucial to the subsequent transitions required to update the
register. Is this up to the adapter specific code to know and compensate
for?
At least one adapter implementation automatically comes out into EXIT1.
Of the 36 transitions in the table, I think that 8 are suspect, and of
those, 2 plain wrong:
DRSHIFT -> DRSHIFT: is 00, depends on answer to 1), but could be 13 or 1D
DRPAUSE -> DRSHIFT: is 20, depends on answer to 1), but could be 13,16,1C
IRSHIFT -> DRSHIFT: is 07, which clocks DR twice, should be 13 or 1D
DRSHIFT -> DRPAUSE: is 01, depends on answer to 1), but could be 17 or 2B
DRSHIFT -> IRSHIFT: is 0F, which clocks IR once, should be 1B
IRSHIFT -> IRSHIFT: is 00, depends on answer to 1), but could be 1B
IRPAUSE -> IRSHIFT: is 20, depends on answer to 1), but could be 1B or 1E
IRSHIFT -> IRPAUSE: is 01, depends on answer to 1), but could be 2F
It's the IRSHIFT->DRSHIFT and vice versa that are definitely wrong.
This may not be a real issue, but it's worth correcting.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Further XScale target issues and adapter comparisons
On Sat, 7 Mar 2009, Duane Ellis wrote: > Peter Denison wrote: >> The symptoms are that the adapter will initialise OK, but toward the end of >> a 'reset halt', after the 2030 TCK cycles, and after loading the Mini >> I-cache, the DCSR write is OK, but the first capture from the TX register >> fails. >> > > peter> This can only be in the adapter-specific code, > > No - it could also be something specific about how the adapter interprets > commands that were not known or a non-issue to other targets. Indeed, but I still think that the locus of the investigation will be the adapter-specific code. > Hmm - how do you know 2030 clocks? Do you have some type of a timing thing > hooked up and watching the pins wiggle? If so it would be interesting to > compare the two traces some how. I did a 'scope trace using the USBprog adapter, but the 'scope has had to go back to work :-(. OK, I didn't count the 2030, but the code in xscale_deassert_reset() does jtag_add_runtest(2030, TAP_IDLE), and the XScale documentation specifies 2030 TCKs after reset before loading the mini-ICache. Sadly, also, I don't have an Olimex-JTAG-Tiny (the working one) here either. The trace for that was done by someone else, half a world away, on an identical target board. So, I can't do direct comparisons unless someone can lend me an Olimex. However, it's not directly after the 2030 TCKs that it goes wrong. All adapters successfully then do a transaction with DCSR, which involves loading IR with 0x9, checking the Capture IR reponse (=0x01), moving to DRSHIFT, and reading/writing the DCSR register. Then all adapters successfully (I think) load the debug handler into the mini-ICache, and write DCSR again. This write to DCSR should then let the target run (the debug code just loaded into the cache), and then the next read is from TX, which the debug handler should have written to. However, the 3 guard bits in fields[0].in_value[3] should be 010 or 011 (from the hardware), and they aren't, which is why I think it's an extra bit clocked somewhere. Many thanks for taking an interest. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Further XScale target issues and adapter comparisons
Still trying to get my IXP422 target board working... I have compared the debug output (with -d3 and _DEBUG_JTAG_IO_ enabled) of someone else's Olimex JTAG-Tiny, which does work, with the output from both an IAR J-Link adapter and the USBprog adapter, which don't work. The target boards were identical models, though not actually the same physical board. The symptoms are that the adapter will initialise OK, but toward the end of a 'reset halt', after the 2030 TCK cycles, and after loading the Mini I-cache, the DCSR write is OK, but the first capture from the TX register fails. This can only be in the adapter-specific code, since some adapters work and others don't, and incidentally the J-Link code was derived from the USBprog code, according to its headers. I wonder if the particular tap state transitions that the J-Link goes through cause a bit to be slipped somehow? (from the traces below, the Olimex show tap_set_state(IDLE) before the DR scan, but the J-Link shows DR_SHIFT, DR_PAUSE, IDLE) I am now beyond the extent of my knowledge, and would appreciate some assistance, particularly from the writers of the FT2232 and J-Link adapter code. One of the things confusing me I think is the reporting of queued state transitions, and not necessary when they get sent to target. Many thanks in advance for any help. Olimex-JTAG-Tiny, on USR8200, IXP422 rev A0 (works) --- Debug: 3710 2653 target.c:3930 jim_target(): target names Debug: 3711 2653 jtag.c:1244 jtag_build_buffer(): num_fields: 1 Debug: 3712 2653 jtag.c:1256 jtag_build_buffer(): fields[0].out_value[7]: 0x10 Debug: 3713 2653 ft2232.c:607 ft2232_add_scan(): tap_set_state(IRSHIFT) Debug: 3714 2653 ft2232.c:735 ft2232_add_scan(): tap_set_state(IDLE) Debug: 3715 2653 ft2232.c:1465 ft2232_execute_queue(): IR scan, 7 bits, end in IDLE Debug: 3716 2653 ft2232.c:576 ft2232_add_pathmove(): tap_set_state(DRSELECT) Debug: 3717 2653 ft2232.c:576 ft2232_add_pathmove(): tap_set_state(DRCAPTURE) Debug: 3718 2653 ft2232.c:576 ft2232_add_pathmove(): tap_set_state(DREXIT1) Debug: 3719 2653 ft2232.c:576 ft2232_add_pathmove(): tap_set_state(DRPAUSE) Debug: 3720 2653 ft2232.c:576 ft2232_add_pathmove(): tap_set_state(DREXIT2) Debug: 3721 2653 ft2232.c:576 ft2232_add_pathmove(): tap_set_state(DRSHIFT) Debug: 3722 2653 ft2232.c:1419 ft2232_execute_queue(): pathmove: 6 states, end in DRSHIFT Debug: 3723 2653 jtag.c:1244 jtag_build_buffer(): num_fields: 3 Debug: 3724 2653 ft2232.c:735 ft2232_add_scan(): tap_set_state(IDLE) Debug: 3725 2653 ft2232.c:1465 ft2232_execute_queue(): DR scan, 36 bits, end in IDLE Debug: 3726 2655 jtag.c:1288 jtag_read_buffer(): fields[0].in_value[7]: 0x01 Debug: 3727 2655 jtag.c:1288 jtag_read_buffer(): fields[0].in_value[3]: 0x03 Debug: 3728 2655 jtag.c:1288 jtag_read_buffer(): fields[1].in_value[32]: 0x0193 Debug: 3729 2655 jtag.c:1288 jtag_read_buffer(): fields[2].in_value[1]: 0x00 Debug: 3730 2655 jtag.c:1244 jtag_build_buffer(): num_fields: 1 Debug: 3731 2655 jtag.c:1256 jtag_build_buffer(): fields[0].out_value[7]: 0x09 Debug: 3732 2655 ft2232.c:607 ft2232_add_scan(): tap_set_state(IRSHIFT) Debug: 3733 2655 ft2232.c:735 ft2232_add_scan(): tap_set_state(DRPAUSE) Debug: 3734 2655 ft2232.c:1465 ft2232_execute_queue(): IR scan, 7 bits, end in DRPAUSE Debug: 3735 2655 jtag.c:1244 jtag_build_buffer(): num_fields: 3 Debug: 3736 2655 jtag.c:1256 jtag_build_buffer(): fields[0].out_value[3]: 0x00 Debug: 3737 2655 jtag.c:1256 jtag_build_buffer(): fields[2].out_value[1]: 0x00 Debug: 3738 2655 ft2232.c:612 ft2232_add_scan(): tap_set_state(DRSHIFT) Debug: 3739 2655 ft2232.c:735 ft2232_add_scan(): tap_set_state(DRPAUSE) Debug: 3740 2655 ft2232.c:1465 ft2232_execute_queue(): DR scan, 36 bits, end in DRPAUSE Debug: 3741 2657 jtag.c:1288 jtag_read_buffer(): fields[0].in_value[7]: 0x01 Debug: 3742 2657 jtag.c:1288 jtag_read_buffer(): fields[0].in_value[3]: 0x02 Debug: 3743 2657 jtag.c:1288 jtag_read_buffer(): fields[1].in_value[32]: 0xC001 Debug: 3744 2657 jtag.c:1288 jtag_read_buffer(): fields[2].in_value[1]: 0x00 === J-Link, on USR8200, IXP422 rev A0 (fails) - Debug: 5020 51449 target.c:3930 jim_target(): target names Debug: 5021 51449 jlink.c:193 jlink_execute_queue(): scan end in 8 Debug: 5022 51449 jtag.c:1244 jtag_build_buffer(): num_fields: 1 Debug: 5023 51449 jtag.c:1256 jtag_build_buffer(): fields[0].out_value[7]: 0x10 Debug: 5024 51449 jlink.c:201 jlink_execute_queue(): scan input, length = 7 Debug: 5025 51449 jlink.c:360 jlink_state_move(): tap_set_state(IRSHIFT) Debug: 5026 51449 jlink.c:436 jlink_scan(): tap_set_state(IRPAUSE) Debug: 5027 51449 jlink.c:360 jlink_state_move(): tap_set_state(IDLE) Debug: 5028 51449 jlink.c:187 jlink_execute_queue(): pathmove: 6 states, end in 3 Debug: 5029 51449 jlink.c:383 jlink_path_move(): tap_set_state(DRSELECT) Debug: 5
[Openocd-development] Using USBprog JTAG adapter on IXP422 target
I've been trying to use USBprog hardware to do JTAG debugging of a US Robotics USR8200 router. This is an XScale target, specifically the IXP422 processor. I know from other people that openocd works with this target with a different JTAG adapter. The communications with the board initially works, and the Manufacturer ID is read out correctly, but things go wrong after a reset is issued. The messages visible on the telnet console are: > reset halt JTAG tap: ixp42x.cpu tap/device found: 0x19277013 (Manufacturer: 0x009, Part: 0x9277, Version: 0x1) JTAG Tap/device matched TAP ixp42x.cpu: value captured during scan didn't pass the requested check: captured: 0x7f check_value: 0x01 check_mask: 0x7f in_handler: w/o "in_value", mismatch in SIR JTAG error while writing DCSR BUG: keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (5357) TAP ixp42x.cpu: value captured during scan didn't pass the requested check: captured: 0x07 check_value: 0x02 check_mask: 0x06 in_handler: with "in_value", mismatch in SDR TAP (unknown): value captured during scan didn't pass the requested check: captured: 0x01 check_value: 0x00 check_mask: 0x01 in_handler: w/o "in_value", mismatch in SDR JTAG error while reading TX error while polling TX register, reset CPU target state: halted What seems to be happening, having traced both the USB traffic and the JTAG traces on a logic analyser, is that the reset starts by resetting both SRST and TRST, then reading the ManID, sending command 0x9 (DCSR?), sending 0x2, and getting the right response, sending command 0x7f (Bypass?), again with the right response. Then SRST is asserted on it's own, and xscale_deassert_reset() calls jtag_add_runtest(2030, TAP_IDLE), and then xscale_write_dscr(target, 1, 0). What is seen on the USB trace and logic trace is toggling of TCK, then a TAP transition of 2B is sent, to do IDLE -> IRSHIFT, but then the write of command 0x9 (DCSR?) returns not 1 as expected, but 0x7f. This implies that the TAP is not in the correct state at that point. This must be localised to src/jtag/usbprog.c, as other adapters work. I wonder if the fact that 2030 transitions of TCK end with the TCK low, interacts badly with the way the "write tms chain" instruction works on the USBprog? It takes TCK low then high, to do each transition, but if TCK is already low at the end of the runtest, one of the transitions would be lost, and the 2B would instead end up as 15, and we'd end up in DRSHIFT, not IRSHIFT. This would be consistent with the read out of 0x7F. Thoughts? What state should TCK be in "normally" - between operations? I'm a little reticent about just putting in a change and trying it without some feedback, in case I damage my target. My proposed change would be raising TCK at the end of usbprog_runtest(), so the next L-H transition of TCK inside the tms-chain function in the firmware has the desired effect. -- Peter Denison ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
