dick hollenbek>
    [duane where are you??? ... snip snip snip]

zach welch>    
    [[I am working my way down to debugging this driver, but I have been   
    waiting for Duane to finish his TAP patches in hope they help.]]

Some things have come up and I'm not going to be able to finish this for 
some period of time :-(  I need some block of "quality time" to deal 
with this, not a few hours here or there. I have lots of those "short 
time periods" just not "quality time".

Would somebody like to help me? I can put together a patch tomorrow 
evening to the point where I'm at.

The stumbling block is this:

    Right now, after my changes, the FT2232 no longer functions correctly.
    I need to fully understand
        (a) what the FT2232 opcode are doing,
        (b) what the tap is expecting to be done.
        (c) I suspect - because of the earlier problem, ie: the FT2232 
outputing different tap sequences then other taps

I suspect, but don't have evidence that this bug is actually a 
combination problem of
    (1) my fix is probably correct, but
    (2) there is/was something else that this needs fixing, now that I 
fixed this step.

The changes, are - on the surface *very* simple,

OLD:
    int tap_get_tms_path(  tap_state_t from, tap_state_t to );
    Return value was:  "7 bits for the tms sequence".

NEW:
    void tap_get_tms_path( tap_state_t from, tap_state_t to, int 
*tms_path, int *tms_len );

This would reference the new tap table that Jeff Williams did a while ago.

The idea is/was:
     (a) the *tms_path* now holds the bit sequence.
     (b) the *tms_len* now holds the number of bits in that sequence.

Then, you just wade through all of the places that GCC complains about 
the parameters being wrong, examine and fix the offending situation. 
Often the solution is simple... There is a simple for( x = 0 ; x < 7 ; 
x++ ) type loop... Those are simple ones.

Would somebody like to "pick up my pieces" and take a closer look at the 
where I'm at?

-Duane.


 



_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to