Can some folks do a quick comparisons of the two tables and tell me
which patch (minimal or w/ optimization) brings the private table closer
in alignment with the main table?
At minimum, it seems like we should take the minimal patch for 0.2.0;
however, the additional optimization should be included too, if that
change makes the private table match the table used by other interfaces.
Cheers,
Zach
On Sun, 2009-07-05 at 13:26 +0200, Ferdinand Postema wrote:
> Sorry, I was not aware of a standard state transistion table. I was
> trying to get my interface working properly and I only looked at the
> code of the amt_jtagaccel interface. I also considdered the minimal
> change. That will also fix the problem.
>
> The reason why this interface has its own state transition table is
> because the jtagaccel interface has two command to initiate a TMS scan
> (I think). One TMS scan command always sends 5 bits. The other command
> can send 1 to 4 bits. The programmer made his own state transition table
> so that he only has to use the command to send out 5 (or 10 bits).
>
> I think, it is a good thing to change the code to use the standard
> table. I was already planning to change it, because I didn't like the
> way this was made. Now that I am aware of a standard state transition
> table, it is an extra reason to do it.
>
>
> Peter Denison schreef:
> > On Sat, 4 Jul 2009, Ferdinand Postema wrote:
> >
> >> I understand that you do not want to make any changes so close to the
> >> release of a new version. No problem.
> >>
> >> I made 3 changes in the table amt_jtagaccel_tap_move. This table defines
> >> how to move from one state to the other. It consists of two bytes per
> >> state move. The five LSB of the first byte will be shifted out to the
> >> right to the TMS-line. If you need an other 5 bytes to reach the desired
> >> state, you have to OR the first word with 0x80 and supply the next 5
> >> bits in the second word (5 LSB).
> >>
> >> The first change is the neccesary one to correct the problem. This is
> >> the sequence to go from state RESET to state DRSHIFT. The value of these
> >> 2 bytes were 0x8a and 0x04. This means that the bitstream to do this
> >> transition is 0b 00100 01010 (send LSB first). This will bring you from
> >> the reset state to the shift state, but you enter the shift-state twice,
> >> which explains why the ID-CODE that will be read next is already shifted
> >> 1 bit. I corrected this to 0x05 and 0x00. This will send te bitstream
> >> 0b00101 (send LSB first). This will bring you from the RESET state to
> >> the DRSHIFT state more directly and without entering the DRSHIFT state
> >> twice.
> >>
> >> After checking the whole table, I found two other transitions that were
> >> correct, but could be optimized (5 bits in stead of 10 bits).
> >> Summary off all changes:
> >> From To Old values Old Bitstream New values New
> >> Bitstream Remark
> >> ---- ------- ---------- ------------- ----------
> >> ------------- ------
> >> RESET DRSHIFT 0x8a 0x04 0b00100 01010 0x05 0x00
> >> 0b00101 To Correct the error (and optimization)
> >> IDLE DRSHIFT 0x85 0x08 0b01000 00101 0x04 0x00 0b00100
> >> Optimization
> >> IDLE IRSHIFT 0x8b 0x08 0b01000 01011 0x06 0x00
> >> 0b00110 Optimization
> >>
> >> Hopefully, this explanation helps.
> >
> > Good explanation.
> >
> > Duane Ellis wrote:
> >> (Forgive me, I have not followed your list of changes and so forth and I
> >> am entering the conversation late).
> >>
> >> One thing we *DO*NOT* want - is one "dongle" - (amt-jtagaccel) to act
> >> differently then some other tap because dongle (A) uses sequence (A),
> >> and another dongle (B) uses sequence (B) for the *exact*same*thing*.
> >>
> >> Please don't mis-understand 'fixing a bug is a correct and good
> >> thing' however optimizing things can introduce bugs.
> >
> > The minimal change that fixes the bug is to just change the RESET to
> > DRSHIFT transition without optimising anything, just changing 0x8a,
> > 0x04 to 0x8a, 0x08. That way the same state transitions are followed,
> > and no optimisation is done. At a later date, perhaps we could look at
> > why this adapter has its own jtag state table...
> >
> > Index: src/jtag/amt_jtagaccel.c
> > ===================================================================
> > --- src/jtag/amt_jtagaccel.c (revision 2461)
> > +++ src/jtag/amt_jtagaccel.c (working copy)
> > @@ -92,7 +92,7 @@
> > static uint8_t amt_jtagaccel_tap_move[6][6][2] =
> > {
> > /* RESET IDLE DRSHIFT DRPAUSE
> > IRSHIFT IRPAUSE */
> > - {{0x1f, 0x00}, {0x0f, 0x00}, {0x8a, 0x04}, {0x0a, 0x00}, {0x06,
> > 0x00}, {0x96, 0x00}}, /* RESET */
> > + {{0x1f, 0x00}, {0x0f, 0x00}, {0x8a, 0x08}, {0x0a, 0x00}, {0x06,
> > 0x00}, {0x96, 0x00}}, /* RESET */
> > {{0x1f, 0x00}, {0x00, 0x00}, {0x85, 0x08}, {0x05, 0x00}, {0x8b,
> > 0x08}, {0x0b, 0x00}}, /* IDLE */
> > {{0x1f, 0x00}, {0x0d, 0x00}, {0x00, 0x00}, {0x01, 0x00}, {0x8f,
> > 0x09}, {0x8f, 0x01}}, /* DRSHIFT */
> > {{0x1f, 0x00}, {0x0c, 0x00}, {0x08, 0x00}, {0x00, 0x00}, {0x8f,
> > 0x09}, {0x8f, 0x01}}, /* DRPAUSE */
> >
> _______________________________________________
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
