Re: [Openocd-development] JTAG, FT2232 and JLink
Magnus Lundin wrote: Hi I was testing the state move work fronm Dick H. when there were a lot of changes in the codebase. As you know I keep working from the same base . There were some problems remaining so I have waited to send the results, but I hope I found most of them now. Here comes my patch. Best regards Magnus New jtag statetables in ft2232 and jlink The parts concering jtag state tables and transitions are from Dick Hollenbeck Some more 7 bit assumptions found in ft2232_add_scan() ft2232_read_scan() In order to work stably with unknown lengths for the last transition out of SHIFT ft2232, for IN and IO scans we now always two steps from SCAN - EXIT1 - PAUSE, to collect the final scanbit, before calling state_move to reach end state. This is the saame behaviour as in JLink driver Nice catch. This was a single bug, not actually two bugs. However this is not the only solution. This solution breaks the contract that the API would like to honor by ignoring the endstate parameter for the cases where the end state is DRSHIFT or IRSHIFT. If there is another way to solve the problem that does not do this, then would it not be superior? Before offering a solution, I mention that the problem is because the ft2232 moves the shifted in bits on the reply to a partial byte command based on the number of clocks. This is the problem. So you have know the number of clocks to get to the partial byte within the full byte reply. Another solution is to record the number of clocks sent out and then use that number later in finding the partial byte. This can be done by recording that number in the command object itself, say in a spare field reserved for the driver. Then later in scan_read() this can be consulted and the partial byte can be found in the buffer within the full byte. This lets you preserve the contract that the API would like to commit to, but is currently not committing to. And it is simple. Dick ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG, FT2232 and JLink
Dick Hollenbeck wrote: Magnus Lundin wrote: Hi I was testing the state move work fronm Dick H. when there were a lot of changes in the codebase. As you know I keep working from the same base . There were some problems remaining so I have waited to send the results, but I hope I found most of them now. Here comes my patch. Best regards Magnus New jtag statetables in ft2232 and jlink The parts concering jtag state tables and transitions are from Dick Hollenbeck Some more 7 bit assumptions found in ft2232_add_scan() ft2232_read_scan() In order to work stably with unknown lengths for the last transition out of SHIFT ft2232, for IN and IO scans we now always two steps from SCAN - EXIT1 - PAUSE, to collect the final scanbit, before calling state_move to reach end state. This is the saame behaviour as in JLink driver Nice catch. This was a single bug, not actually two bugs. However this is not the only solution. This solution breaks the contract that the API would like to honor by ignoring the endstate parameter for the cases where the end state is DRSHIFT or IRSHIFT. If there is another way to solve the problem that does not do this, then would it not be superior? No, there is a separate check to se if endstate is SHIFT, and then all data is transferred with Clock Data Bits and we never leave the SCAN state. But the JLink driver does not handle this situation correctly. Regards Magnus ___ 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 Mon, May 18, 2009 at 6:36 AM, Rick Altherr kc8...@kc8apf.net wrote: 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. Could you take charge of merging in this code in a suitable # of commits? I don't have that hardware handy to talk to + I'm away some this week and all of next. In terms of getting 0.2 out of the door it would be nice to have all major projects synched up before we start testing rounds... -- Ø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] 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] 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
[Openocd-development] JTAG, FT2232 and JLink
Hi
I was testing the state move work fronm Dick H. when there were a lot of
changes in the codebase. As you know I keep working from the same base .
There were some problems remaining so I have waited to send the results,
but I hope I found most of them now.
Here comes my patch.
Best regards
Magnus
New jtag statetables in ft2232 and jlink
The parts concering jtag state tables and transitions are from Dick
Hollenbeck
Some more 7 bit assumptions found in
ft2232_add_scan()
ft2232_read_scan()
In order to work stably with unknown lengths for the last transition out
of SHIFT ft2232,
for IN and IO scans we now always two steps from SCAN - EXIT1 - PAUSE,
to collect the final scanbit,
before calling state_move to reach end state. This is the saame
behaviour as in JLink driver
JLink driver has been tweaked and now runs stable. Buffersizes has been
reduced allowing maximum jtag speed
without killing the Linux usb stack.
There is a change from malloc to calloc in jtag.c:jtag_build_buffer()
This removed most weird errors from JLink+ARM7_9 combinations.
Shortest path state moves has been tested with both drivers against
OMAP3530, STM32, ARM926ejs (imx21), LPC2124
Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c (revision 1606)
+++ src/jtag/jlink.c (working copy)
@@ -44,6 +44,11 @@
#define JLINK_USB_TIMEOUT 1000
// See Section 1.3.2 of the Segger JLink USB protocol manual
+/* 2048 is the max value we can use here */
+//#define JLINK_TAP_BUFFER_SIZE 2048
+#define JLINK_TAP_BUFFER_SIZE 256
+//#define JLINK_TAP_BUFFER_SIZE 384
+
#define JLINK_IN_BUFFER_SIZE 2048
#define JLINK_OUT_BUFFER_SIZE 2*2048+4
#define JLINK_EMU_RESULT_BUFFER_SIZE 64
@@ -57,8 +62,11 @@
#define EMU_CMD_VERSION 0x01
#define EMU_CMD_SET_SPEED 0x05
#define EMU_CMD_GET_STATE 0x07
+#define EMU_CMD_HW_CLOCK 0xc8
+#define EMU_CMD_HW_TMS0 0xc9
+#define EMU_CMD_HW_TMS1 0xca
#define EMU_CMD_HW_JTAG3 0xcf
-#define EMU_CMD_GET_MAX_MEM_BLOCK 0xd4
+#define EMU_CMD_GET_MAX_MEM_BLOCK 0xd4
#define EMU_CMD_HW_RESET0 0xdc
#define EMU_CMD_HW_RESET1 0xdd
#define EMU_CMD_HW_TRST0 0xde
@@ -183,7 +191,7 @@
enum scan_type type;
u8 *buffer;
- DEBUG_JTAG_IO(scan end in %i, cmd-cmd.scan-end_state);
+ DEBUG_JTAG_IO(scan end in %s, tap_state_name(cmd-cmd.scan-end_state));
if (cmd-cmd.scan-end_state != TAP_INVALID)
jlink_end_state(cmd-cmd.scan-end_state);
@@ -206,10 +214,13 @@
jlink_tap_execute();
- if (cmd-cmd.reset-trst == 1)
+ if ( (cmd-cmd.reset-trst == 1) || ( cmd-cmd.reset-srst (jtag_reset_config RESET_SRST_PULLS_TRST) ) )
+ {
tap_set_state(TAP_RESET);
+ }
jlink_reset(cmd-cmd.reset-trst, cmd-cmd.reset-srst);
+ jlink_tap_execute();
}
static void jlink_execute_sleep(jtag_command_t *cmd)
@@ -333,6 +344,7 @@
LOG_INFO(J-Link JTAG Interface ready);
jlink_reset(0, 0);
+ jtag_sleep(3000);
jlink_tap_init();
jlink_speed(jtag_speed);
@@ -367,8 +379,9 @@
int i;
int tms = 0;
u8 tms_scan = tap_get_tms_path(tap_get_state(), tap_get_end_state());
+ u8 tms_scan_bits = tap_get_tms_path_len(tap_get_state(), tap_get_end_state());
- for (i = 0; i 7; i++)
+ for (i = 0; i tms_scan_bits; i++)
{
tms = (tms_scan i) 1;
jlink_tap_append_step(tms, 0);
@@ -409,11 +422,14 @@
tap_state_t saved_end_state = tap_get_end_state();
+ jlink_tap_ensure_space(1,num_cycles + 16);
+
/* only do a state_move when we're not already in IDLE */
if (tap_get_state() != TAP_IDLE)
{
jlink_end_state(TAP_IDLE);
jlink_state_move();
+// num_cycles--;
}
/* execute num_cycles */
@@ -434,7 +450,7 @@
{
tap_state_t saved_end_state;
- jlink_tap_ensure_space(1, scan_size + 8);
+ jlink_tap_ensure_space(1, scan_size + 16);
saved_end_state = tap_get_end_state();
@@ -469,24 +485,23 @@
if (srst == 0)
{
jlink_simple_command(EMU_CMD_HW_RESET1);
- jlink_end_state(TAP_RESET);
- jlink_state_move();
}
- else if (srst == 1)
+ if (srst == 1)
{
jlink_simple_command(EMU_CMD_HW_RESET0);
}
+ if (trst == 1)
+ {
+ jlink_simple_command(EMU_CMD_HW_TRST0);
+ }
if (trst == 0)
{
jlink_simple_command(EMU_CMD_HW_TRST1);
+ jtag_sleep(5000);
jlink_end_state(TAP_RESET);
jlink_state_move();
}
- else if (trst == 1)
- {
- jlink_simple_command(EMU_CMD_HW_TRST0);
- }
}
static void jlink_simple_command(u8 command)
@@ -601,10 +616,8 @@
/***/
/* J-Link tap functions */
-/* 2048 is the max value we can use here */
-#define JLINK_TAP_BUFFER_SIZE 2048
-static unsigned tap_length;
+static unsigned tap_length=0;
static u8 tms_buffer[JLINK_TAP_BUFFER_SIZE];
static u8 tdi_buffer[JLINK_TAP_BUFFER_SIZE];
static u8 tdo_buffer[JLINK_TAP_BUFFER_SIZE];
@@ -631,7 +644,7 @@
static void jlink_tap_ensure_space(int scans, int bits)
{
int available_scans =
Re: [Openocd-development] JTAG, FT2232 and JLink
Øyvind Harboe wrote: I've made a quick attempt at modifying the patch to be against svn head, can't test beyond building it though. This took me a couple of minutes, so this patch is only very slightly different in svn head/1606. Looking at the patch, it occurs to me that from a testing/bisection point of view, it would be possible to break this into a number of patches. This would be *greatly* helpful if we need to go back and check if something subtle broke here... ? Well, the modifications to jtag.c are very minor :) The ft2232 stuff is actually a unit, it will hardly build otherwise (Dick told us so and here he was right) I did not include the 2232h and the reconnect parts, they can (easily) be applied later. The JLink is separate and it will be clear if we are using jlink or ft2232 :) I think you should be happy that I did not include the cortex work in this patch, thats a big one ... Have a great evening Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG, FT2232 and JLink
I'd like to see the jtag.c changes as patch #1, ft2232 as #2, and JLink as #3. I'm fine with the ft2232 being a big patch, but I don't like having the JTAG changes mixed with the drivers. Is there a reason we shouldn't apply the jtag.c changes now? -- Ø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] JTAG, FT2232 and JLink
On May 15, 2009, at 11:35 AM, Øyvind Harboe wrote: I'd like to see the jtag.c changes as patch #1, ft2232 as #2, and JLink as #3. I'm fine with the ft2232 being a big patch, but I don't like having the JTAG changes mixed with the drivers. Is there a reason we shouldn't apply the jtag.c changes now? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com I don't believe so. They seem to be completely harmless until the driver chooses to opt-in. -- 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
So apply this patch?
Can anyone test?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
Index: C:/workspace/openocd/src/jtag/jtag.c
===
--- C:/workspace/openocd/src/jtag/jtag.c(revision 1793)
+++ C:/workspace/openocd/src/jtag/jtag.c(working copy)
@@ -853,6 +853,9 @@
#endif
}
}
+
+ /* field_count represents the true number of fields setup*/
+ (*last_cmd)-cmd.scan-num_fields = field_count;
return ERROR_OK;
}
@@ -1315,7 +1318,7 @@
int i;
bit_count = jtag_scan_size(cmd);
- *buffer = malloc(CEIL(bit_count, 8));
+ *buffer = calloc(1,CEIL(bit_count, 8));
bit_count = 0;
@@ -3271,7 +3274,7 @@
#define B8(bits,count) { ((u8)B8__(HEX__(bits))), (count) }
-#if 0 ((BUILD_FT2232_FTD2XX==1) || (BUILD_FT2232_LIBFTDI==1) ||
(BUILD_JLINK==1))
+#if 1 ((BUILD_FT2232_FTD2XX==1) || (BUILD_FT2232_LIBFTDI==1) ||
(BUILD_JLINK==1))
/* this is the table submitted by Jeff Williams on 3/30/2009 with
this comment:
OK, I added Peter's version of the state table, and it works OK
for
@@ -3298,10 +3301,10 @@
/* to state: */
/* RESET IDLEDRSHIFT
DRPAUSE IRSHIFT IRPAUSE */
/* from state: */
- { B8(111,7), B8(0,1),B8(00101,5),
B8(01010,5),B8(001101,6), B8(010110,6) }, /* RESET */
- { B8(111,7), B8(0,1),B8(001,3),
B8(0101,4), B8(0011,4), B8(01011,5) }, /* IDLE
*/
+ { B8(111,7), B8(000,7), B8(00101,5),
B8(01010,5),B8(001101,6), B8(010110,6) }, /* RESET */
+ { B8(111,7), B8(000,7), B8(001,3),
B8(0101,4), B8(0011,4), B8(01011,5) }, /* IDLE */
{ B8(111,7), B8(011,3), B8(00111,5),
B8(01,2), B8(00,6), B8(010,7) },/*
DRSHIFT */
- { B8(111,7), B8(011,3), B8(01,2),
B8(0,1),B8(00,6), B8(010,7) },
/* DRPAUSE */
+ { B8(111,7), B8(011,3), B8(01,2),
B8(0,1),B8(00,6), B8(010,7) },/*
DRPAUSE */
{ B8(111,7), B8(011,3), B8(00111,5),
B8(010111,6), B8(00,6), B8(01,2) }, /* IRSHIFT */
{ B8(111,7), B8(011,3), B8(00111,5),
B8(010111,6), B8(01,2), B8(0,1) } /*
IRPAUSE */
@@ -3308,13 +3311,13 @@
#else /* this is the old table, converted from hex and with the bit_count set
to 7 for each combo, like before */
/* to state: */
- /* RESET IDLEDRSHIFT
DRPAUSE IRSHIFT IRPAUSE */
/* from state: */
- { B8(111,7), B8(000,7), B8(0010111,7), B8(0001010,7),
B8(0011011,7), B8(0010110,7) },/* RESET */
- { B8(111,7), B8(000,7), B8(0100101,7), B8(101,7),
B8(0101011,7), B8(0001011,7) },/* IDLE */
- { B8(111,7), B8(0110001,7), B8(000,7), B8(001,7),
B8(000,7), B8(010,7) },/* DRSHIFT */
- { B8(111,7), B8(011,7), B8(010,7), B8(0010111,7),
B8(000,7), B8(010,7) },/* DRPAUSE */
- { B8(111,7), B8(0110001,7), B8(111,7), B8(0010111,7),
B8(000,7), B8(001,7) },/* IRSHIFT */
- { B8(111,7), B8(011,7), B8(0011100,7), B8(0010111,7),
B8(010,7), B8(010,7) } /* IRPAUSE */
+ /* RESET IDLEDRSHIFT
DRPAUSE IRSHIFT IRPAUSE */
/* from state: */
+ { B8(111,7), B8(000,7), B8(0010111,7), B8(0001010,7),
B8(0011011,7), B8(0010110,7) },/* RESET */
+ { B8(111,7), B8(000,7), B8(0100101,7), B8(101,7),
B8(0101011,7), B8(0001011,7) },/* IDLE */
+ { B8(111,7), B8(0110001,7), B8(000,7), B8(001,7),
B8(000,7), B8(010,7) },/* DRSHIFT */
+ { B8(111,7), B8(011,7), B8(010,7), B8(0010111,7),
B8(000,7), B8(010,7) },/* DRPAUSE */
+ { B8(111,7), B8(0110001,7), B8(111,7), B8(0010111,7),
B8(000,7), B8(001,7) },
Re: [Openocd-development] JTAG, FT2232 and JLink
Øyvind Harboe wrote: So apply this patch? Can anyone test? I can try with jlink (which I have not been able to get to work yet, see my previous post: j-link/jlink attempt). -gene ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
