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 [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
