#121 Manually-specified JTAG chain contents leads to incorrect IR shifts.
Manually-specified JTAG chain contents leads to incorrect IR shifts.
When using addpart() to manually specify the contents of the JTAG chain, urjtag will undershift the JTAG chain on the first scan operation. For example, say that we have used addpart() to add 10 devices to urjtag's chain, each with an IR length of 8. This means the actual length of the IR chain is 80 bits. On the first JTAG operation afterwards, I've observed on a logic analyzer that urjtag will actually perform a series of IR shifts, most of which are too short:
IR shift of 8 bits
IR shift of 16 bits
IR shift of 24 bits
...
IR shift of 72 bits
IR shift of 80 bits (This is finally long enough for the entire chain!)
The problem is that for all of the shifts that are too short, this undershifting results in the devices closest to the end of the chain getting incorrect IR values shifted into them (the IR capture values of upstream devices). In my work, I have observed undesirable behavior from downstream devices as they get these unintended IR values
The correct behavior would be for urjtag to do a single IR shift of 80 bits right off the bat.
I should add: Subsequent IR shift operations after the first one are the correct length.
This appears to be a problem in the Python bindings, not urjtag itself. The urj_pyc_addpart() function calls urj_tap_chain_shift_instructions() after adding the part. This will cause a too-short IR shift after each part is added, an finally a proper-length IR shift after the last part has been added.