Magnus Lundin wrote: > Hi > > I was testing the state move work fronm Dick H. when there were a lot > of changes in the codebase. As you know I keep working from the same > base . There were some problems remaining so I have waited to send the > results, but I hope I found most of them now. > > Here comes my patch. > > Best regards > Magnus > > > New jtag statetables in ft2232 and jlink > ======================================== > > The parts concering jtag state tables and transitions are from Dick > Hollenbeck > > Some more 7 bit assumptions found in > ft2232_add_scan() > ft2232_read_scan() > > In order to work stably with unknown lengths for the last transition > out of SHIFT ft2232, > for IN and IO scans we now always two steps from SCAN -> EXIT1 -> > PAUSE, to collect the final scanbit, before calling state_move to > reach end state. This is the saame behaviour as in JLink driver
Nice catch. This was a single bug, not actually two bugs. However this is not the only solution. This solution breaks the contract that the API would like to honor by ignoring the endstate parameter for the cases where the end state is DRSHIFT or IRSHIFT. If there is another way to solve the problem that does not do this, then would it not be superior? Before offering a solution, I mention that the problem is because the ft2232 moves the shifted in bits on the reply to a "partial byte command" based on the number of clocks. This is the problem. So you have know the number of clocks to get to the partial byte within the full byte reply. Another solution is to record the number of clocks sent out and then use that number later in finding the partial byte. This can be done by recording that number in the command object itself, say in a spare field reserved for the driver. Then later in scan_read() this can be consulted and the partial byte can be found in the buffer within the full byte. This lets you preserve the contract that the API would like to commit to, but is currently not committing to. And it is simple. Dick _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
