|
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 luck with your 0.2.0 branch release! P.S. I'm working on the code of the amt_jtagaccel interface to incorporate speed setting in kHz. Ferdinand Postema Zach Welch schreef: Without further confirmation of this patch's correctness, I do not want to add it until after the 0.2.0 branch release. I have been trying to push that out for most of the week, but it would be good to include this fix if it is indeed required.Can you perhaps provide a little more explanation regarding why you believe this patch to be correct? Sorry for having to ask, but I need to learn the details in order to make an informed decision about it. On Fri, 2009-07-03 at 22:16 +0200, Ferdinand Postema wrote: |
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
