On Friday 29 January 2010, Matthew Fletcher wrote: > > >> There appears to be a certain amount of rot in the amt_jtagaccel driver, > > > >That was my conclusion when I noticed, not long ago, that > >it wouldn't even *build* with PPDEV enabled ... an issue > >that's been around for quite some time. > > I can post a patch for review of some of the fixups i've done so far,
That'd be good. If anything isn't yet suitable for merging (given that the 0.4.0-RC phase is nearing its end), please split that out separately. > but i think > amt_jtagaccel / common_arm7-9 needs some attention as stepping in arm thumb > mode seems to cause invalid instruction traps and is generally pretty > unstable. I think it was Nico who had a bunch of Thumb stepping fixes. The quantity made me suspect there were likely more issues lurking in that code! I confess the only Thumb stepping I've done has been on Cortex-M3; not the same. Are you testing on a chip with an ICE that does hardware stepping? > >Those unexpected IDCODE message, like > > > >> Warn : Unexpected idcode after end of chain: 320 0x8000007f > > > >are frequently caused by clocking problems. The correct > >values would be 0x000000ff ... a one-bit shift of what > >is actually reported. > > Getting the scope out showed that the jtag clock lines RTCK/TCK were not > showing anything, dropping the speed down to 500khz and then letting the RTCK > be > the master clock seemed to fix these. Hmmm ... there are also bugs in the adaptive clocking support for amt_jtagaccel. There should be some FIXME comment there; minimally, use the generic interface to that functionality instead of a driver-specific version. > Ended up hacking the code to do this as the driver code > was easier to understand than the option parsing ! I'm not clear what you mean by that ... - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
