Микроконтроллеры

в новых ATmega errata в конце datasheet, перед содержанием Errata The revision letter in this section refers to the revision of the ATmega64 device. ATmega64, all rev. • Stabilizing time needed when changing XDIV Register • Stabilizing time needed when changing OSCCAL Register 1. Stabilizing time needed when changing XDIV Register After increasing the source clock frequency more than 2% with settings in the XDIV register, the device may execute some of the subsequent instructions incorrectly. Problem Fix / Workaround The NOP instruction will always be executed correctly also right after a frequency change. Thus, the next 8 instructions after the change should be NOP instructions. To ensure this, follow this procedure: 1.Clear the I bit in the SREG Register. 2.Set the new pre-scaling factor in XDIV register. 3.Execute 8 NOP instructions 4.Set the I bit in SREG This will ensure that all subsequent instructions will execute correctly. Assembly Code Example: CLI ; clear global interrupt enable OUT XDIV, temp ; set new prescale value NOP ; no operation NOP ; no operation NOP ; no operation NOP ; no operation NOP ; no operation NOP ; no operation NOP ; no operation NOP ; no operation SEI ; clear global interrupt enable 2. Stabilizing time needed when changing OSCCAL Register After increasing the source clock frequency more than 2% with settings in the OSCCAL register, the device may execute some of the subsequent instructions incorrectly. Problem Fix / Workaround The behavior follows errata number 1., and the same Fix / Workaround is applicable on this errata. A proposal for solving problems regarding the JTAG instruction IDCODE is presented below. 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 shifting 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 ATmega64 is the only device in the scan chain, the problem is not visible. Problem Fix / Workaround Select the Device ID Register of the ATmega64 (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 ATmega64 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 ATmega64. 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 ATmega64 is the fist 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.