Albert ARIBAUD a écrit : > David Brownell a écrit : >> On Tuesday 24 November 2009, Albert ARIBAUD wrote: >>> I did investigate by fixing 0x3 directly in feroceon.cfg, and it does >>> not improve: >>> >>>> Error: IR capture error at bit 4, saw 0x09 not 0x...3 >> Are you sure you didn't make the "ircapture" be 0x3, >> instead of the "irmask"? Because masking the two LSBs (0x3) >> of 0x09 gives 0x01, the specified "ircapture" value. > > Yes, I am sure. I triple-checked feroceon.cfg: > >> jtag newtap $_CHIPNAME cpu -irlen 32 -ircapture 0x1 -irmask 0x3 -expected-id >> $_CPUTAPID > > This is what gave the results I gave in my previous post.
Added info: I tried putting the JTAG in BYPASS and then shift data through it, using the following commands: > irscan feroceon.cpu 0xf > drscan feroceon.cpu 32 0xffaa0055 Using the -irlen 32, the result is: > C0E28618 ... whatever value I shift in DR: >> drscan feroceon.cpu 32 0 > C0E28618 >> drscan feroceon.cpu 32 0xffffffff > C0E28618 So, obviously, -irlen 32 is not correct (that was to be expected). Now with -irlen 4: >> irscan feroceon.cpu 0xf >> drscan feroceon.cpu 32 0xffaa0055 > FF5400AA >> drscan feroceon.cpu 32 0 > 00000000 >> drscan feroceon.cpu 32 0xffffffff > FFFFFFFE That's way better, and seems to work as described by e.g. ARM9EJ-S TRM annex B.4: TDO is TDI with a 1-bit left shift, and MSB forced at 0. So now I'm completely sure the right irlen setting is 4. Still, I cannot talk to the target, and even trying to get IDCODE does not work -- weirder yet: - doing an "irscan feroceon.cpu 0xe" right after my BYPASS test causes a target reboot; - doing it after a "jtag arp_init" does not reboot, but then a drscan 0x32 0 returns 0, which is not the IDCODE seen by OpenOCD. Amicalement, -- Albert. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
