IDCODE masks data from TDI input
The public but optional JTAG instruction IDCODE is not implemented correctly according to
IEEE1149.1; a logic one is scanned into the shift register instead of the TDI input while shift-
ing the Device ID Register. Hence, captured data from the preceding devices in the
boundary scan chain are lost and replaced by all-ones, and data to succeeding devices are
replaced by all-ones during Update-DR.
If ATmega162 is the only device in the scan chain, the problem is not visible.
Problem Fix / Workaround
Select the Device ID Register of the ATmega162 (Either by issuing the IDCODE instruction
or by entering the Test-Logic-Reset state of the TAP controller) to read out the contents of
its Device ID Register and possibly data from succeeding devices of the scan chain. Note
that data to succeeding devices cannot be entered during this scan, but data to preceding
devices can. Issue the BYPASS instruction to the ATmega162 to select its Bypass Register
while reading the Device ID Registers of preceding devices of the boundary scan chain.
Never read data from succeeding devices in the boundary scan chain or upload data to the
succeeding devices while the Device ID Register is selected for the ATmega162. Note that
the IDCODE instruction is the default instruction selected by the Test-Logic-Reset state of
the TAP-controller.
Alternative Problem Fix / Workaround
If the Device IDs of all devices in the boundary scan chain must be captured simultaneously
(for instance if blind interrogation is used), the boundary scan chain can be connected in
such way that the ATmega162 is the first device in the chain. Update-DR will still not work
for the succeeding devices in the boundary scan chain as long as IDCODE is present in the
JTAG Instruction Register, but the Device ID registered cannot be uploaded in any case.
request.