Sorry, I have to learn to post messages as plaint-text and not as html!
It is not possible to match the private table to the table used by other
interfaces, because the code can only send 5 or 10 bits. I think my
patch (including the optimization) brings the private table closer to
the table used by other interfaces. The best option is to change the
code to use the same table as the other interfaces. I am working on that
option, but I think it will not be finished and tested before the 0.2.0
release.
Comparison of the TMS bitstreams:
from to std. opt. min.change
----- ------- ------- ----- ----------
RESET DRSHIFT 0010111 00101 0100001010
IDLE DRSHIFT 001 00100 0100000101
IDLE IRSHIFT 0011 00110 0100001011
Cheers,
Ferdinand Postema
Zach Welch schreef:
> 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
