**** BEGIN LOGGING AT Sun Mar 01 02:59:57 2009 Mar 01 08:49:52 sn9: Noticed a possible relevant fact - the J-link support was based on the USBprog support, and both fail Mar 01 13:15:14 noz: interesting Mar 01 13:30:55 keesj: ping Mar 01 13:31:24 yo Mar 01 13:31:49 * keesj is hunting weird arm11 behaviour for a change Mar 01 13:31:54 wassup? Mar 01 13:32:45 You don't have the TI JTAG document? Mar 01 13:33:03 No Mar 01 13:33:22 Well I have the .doc document that Jason sent Mar 01 13:33:45 yes, this one "Emulation section in TRM.doc" is the name on my disk Mar 01 13:35:35 keesj: One page 5/8 in that doc below the JTAG pin table there is "Before starting the debugger, the debug power domain must be activated by applying a minimum of 10 TCK pulses to the OMAP3430 device after nTRST is pulled high." Mar 01 13:36:36 I see Mar 01 13:38:21 the "fun thing" is that urjtag did something similar already (It was a little different but about the same behaviour) Mar 01 13:38:54 keesj: Do you have 5min to check if you can help me about what jtag_validate_chain() in trunk/jtag/jtag.c might do? Just to check if you have an idea or if I have to ask at mailing list. Mar 01 13:39:12 sure Mar 01 13:39:55 I think I already looked at it for quite a long time already Mar 01 13:40:23 In our case, in jtag_validate_chain() an ir_test of length 8 (6 +2) is filled with all 1 and then a jtag_add_plain_ir_scan() is done Mar 01 13:41:13 Why do they expect 0x3 for val?? if(val != 0x3) Mar 01 13:41:58 The working original version returns Mar 01 13:42:02 Chain pos: 6, ir_test: 0x000000c1 Mar 01 13:42:12 I.e pos 6 is 0x3 Mar 01 13:42:32 but I have no idea why shifting all 1 into it results in output 0xc1 Mar 01 13:43:19 it does a ir_test = malloc(CEIL(total_ir_length, 8)); Mar 01 13:43:28 hmm Mar 01 13:43:29 wait Mar 01 13:44:27 yes, ir_test is 8 bit long and filled with 1 (buf_set_ones) Mar 01 13:44:30 and jtag_add_plain_ir_scan(1, &field, TAP_RESET); doesn't look good to me :p Mar 01 13:45:06 so it must be looking at the single 6 bits long initial buffer right Mar 01 13:45:31 it send 8 ones right Mar 01 13:45:55 yes, and then gets back 0xc1 Mar 01 13:46:16 and then checks for 0x1 at pos 0 and 0x3 at pos 6 Mar 01 13:46:35 but what is the idea behind this? Mar 01 13:47:23 it works, but I'd like to understand it, as in my modified code it fails and I'd like to understand why ;) Mar 01 13:52:41 dirk2: Wat it does think is "simply" checking that all the values returned are ones Mar 01 13:54:01 keesj: hmm, and why is it 0xc1, i.e. '1100 0001' ? Mar 01 13:54:12 no , what it does is that for every tap check that the first /last bit is a one Mar 01 13:57:37 it must be becasue the "current" instruction whas that value right? Mar 01 13:58:02 when you shift ir you read the :last: value that was in there Mar 01 13:58:50 isnt' the 11000 one of the IR instruction in your code? Mar 01 14:00:20 BTW does the 10 TCK artifact also means we actualy CAN pass via RESET as long as we dont' issue 10 + cycles? Mar 01 14:02:09 I don't think so. The 10 TCK are necessary to get the TAP enabled the first time Mar 01 14:02:28 I wasn't able to get the ICDPICK ID without doing the 10 TCK Mar 01 14:03:42 under openocd? Mar 01 14:03:47 yes Mar 01 14:04:35 O wait Mar 01 14:04:42 The original OpenOCD has this "do always 7 clocks" state machine you mentioned at mailing list Mar 01 14:05:11 So the first 7 TAP_RESET to TAP_RESET clocks are enough to enable ICEPICK Mar 01 14:05:55 dirk2: I can easly check such stuff using the analyzer btw Mar 01 14:06:04 but I played a little with the new TMS calculation from Holger Mar 01 14:06:33 and this does only 1 TAP_RESET clock, as it is intended to do things 'correctly' Mar 01 14:06:48 but then no ICEPICK ID any more Mar 01 14:07:55 I.e. the 7 clocks state machine enabled OMAP3 JTAG correctly by accident ;) Mar 01 14:09:08 After I fixed this, I'm now stuck with 0xc1 check we discussed above Mar 01 14:09:21 with Holger's state machine I get 0x41 Mar 01 14:11:50 This is most probably related to this strange TMS manipulation Mar 01 14:11:53 BUFFER_ADD = tap_get_tms_path( tap_get_state(), tap_get_end_state() ) | (last_bit << 7); Mar 01 14:11:58 in ft2232.c Mar 01 14:12:00 so for the scan_chain verification I don Mar 01 14:12:23 't know . I suspect some standard that the first bit is always one or similar Mar 01 14:13:07 hmm, ok, sounds like asking at mailing list ;) thanks Mar 01 14:14:05 Would be nice to have Rick or Duane here for some minutes ;) Mar 01 14:14:44 indeed Mar 01 14:15:12 event to help people with configuration problems as this is really a problem that is apparent on this channel **** ENDING LOGGING AT Mon Mar 02 02:59:57 2009