ATmega128 (961723), страница 68
Текст из файла (страница 68)
1, VMMD.9.00 BSC5.20EE2NOTE5.405.609.00 BSC5.20e5.405.600.50 BSCL0.350.400.45K0.20––8/19/04R3722325 Orchard ParkwaySan Jose, CA 95131TITLE64M1, 64-pad, 9 x 9 x 1.0 mm Body, Lead Pitch 0.50 mm,5.40 mm Exposed Pad, Micro Lead Frame Package (MLF)DRAWING NO.64M1REV.DATmega1282467M–AVR–11/04ATmega128ErrataThe revision letter in this section refers to the revision of the ATmega128 device.ATmega128 Rev. I• Stabilizing time needed when changing XDIV Register• Stabilizing time needed when changing OSCCAL Register1. Stabilizing time needed when changing XDIV RegisterAfter increasing the source clock frequency more than 2% with settings in the XDIVregister, the device may execute some of the subsequent instructions incorrectly.Problem Fix / WorkaroundThe NOP instruction will always be executed correctly also right after a frequencychange.
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 instructions4.Set the I bit in SREGThis will ensure that all subsequent instructions will execute correctly.Assembly Code Example:CLIOUT; clear global interrupt enableXDIV, temp; set new prescale valueNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationSEI; clear global interrupt enable2. Stabilizing time needed when changing OSCCAL RegisterAfter increasing the source clock frequency more than 2% with settings in the OSCCAL register, the device may execute some of the subsequent instructionsincorrectly.Problem Fix / WorkaroundThe behavior follows errata number 1., and the same Fix / Workaround is applicableon this errata.A proposal for solving problems regarding the JTAG instruction IDCODE is presentedbelow.IDCODE masks data from TDI inputThe public but optional JTAG instruction IDCODE is not implemented correctlyaccording to IEEE1149.1; a logic one is scanned into the shift register instead of theTDI 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, anddata to succeeding devices are replaced by all-ones during Update-DR.If ATmega128 is the only device in the scan chain, the problem is not visible.3732467M–AVR–11/04Problem Fix / WorkaroundSelect the Device ID Register of the ATmega128 (Either by issuing the IDCODEinstruction or by entering the Test-Logic-Reset state of the TAP controller) to readout the contents of its Device ID Register and possibly data from succeedingdevices of the scan chain. Note that data to succeeding devices cannot be enteredduring this scan, but data to preceding devices can. Issue the BYPASS instructionto the ATmega128 to select its Bypass Register while reading the Device ID Registers of preceding devices of the boundary scan chain.
Never read data fromsucceeding devices in the boundary scan chain or upload data to the succeedingdevices while the Device ID Register is selected for the ATmega128. Note that theIDCODE instruction is the default instruction selected by the Test-Logic-Reset stateof the TAP-controller.Alternative Problem Fix / WorkaroundIf 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 canbe connected in such way that the ATmega128 is the fist device in the chain.Update-DR will still not work for the succeeding devices in the boundary scan chainas long as IDCODE is present in the JTAG Instruction Register, but the Device IDregistered cannot be uploaded in any case.ATmega128 Rev. H• Stabilizing time needed when changing XDIV Register• Stabilizing time needed when changing OSCCAL Register1.
Stabilizing time needed when changing XDIV RegisterAfter increasing the source clock frequency more than 2% with settings in the XDIVregister, the device may execute some of the subsequent instructions incorrectly.Problem Fix / WorkaroundThe NOP instruction will always be executed correctly also right after a frequencychange. 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 instructions4.Set the I bit in SREGThis will ensure that all subsequent instructions will execute correctly.Assembly Code Example:CLIOUT374; clear global interrupt enableXDIV, temp; set new prescale valueNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationSEI; clear global interrupt enableATmega1282467M–AVR–11/04ATmega1282.
Stabilizing time needed when changing OSCCAL RegisterAfter increasing the source clock frequency more than 2% with settings in the OSCCAL register, the device may execute some of the subsequent instructionsincorrectly.Problem Fix / WorkaroundThe behavior follows errata number 1., and the same Fix / Workaround is applicableon this errata.A proposal for solving problems regarding the JTAG instruction IDCODE is presentedbelow.IDCODE masks data from TDI inputThe public but optional JTAG instruction IDCODE is not implemented correctlyaccording to IEEE1149.1; a logic one is scanned into the shift register instead of theTDI 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, anddata to succeeding devices are replaced by all-ones during Update-DR.If ATmega128 is the only device in the scan chain, the problem is not visible.Problem Fix / WorkaroundSelect the Device ID Register of the ATmega128 (Either by issuing the IDCODEinstruction or by entering the Test-Logic-Reset state of the TAP controller) to readout the contents of its Device ID Register and possibly data from succeedingdevices of the scan chain.
Note that data to succeeding devices cannot be enteredduring this scan, but data to preceding devices can. Issue the BYPASS instructionto the ATmega128 to select its Bypass Register while reading the Device ID Registers of preceding devices of the boundary scan chain. Never read data fromsucceeding devices in the boundary scan chain or upload data to the succeedingdevices while the Device ID Register is selected for the ATmega128. Note that theIDCODE instruction is the default instruction selected by the Test-Logic-Reset stateof the TAP-controller.Alternative Problem Fix / WorkaroundIf 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 canbe connected in such way that the ATmega128 is the fist device in the chain.Update-DR will still not work for the succeeding devices in the boundary scan chainas long as IDCODE is present in the JTAG Instruction Register, but the Device IDregistered cannot be uploaded in any case.ATmega128 Rev.
G• Stabilizing time needed when changing XDIV Register• Stabilizing time needed when changing OSCCAL Register1. Stabilizing time needed when changing XDIV RegisterAfter increasing the source clock frequency more than 2% with settings in the XDIVregister, the device may execute some of the subsequent instructions incorrectly.Problem Fix / WorkaroundThe NOP instruction will always be executed correctly also right after a frequencychange. 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.3752467M–AVR–11/043.Execute 8 NOP instructions4.Set the I bit in SREGThis will ensure that all subsequent instructions will execute correctly.Assembly Code Example:CLIOUT; clear global interrupt enableXDIV, temp; set new prescale valueNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationSEI; clear global interrupt enable2.
Stabilizing time needed when changing OSCCAL RegisterAfter increasing the source clock frequency more than 2% with settings in the OSCCAL register, the device may execute some of the subsequent instructionsincorrectly.Problem Fix / WorkaroundThe behavior follows errata number 1., and the same Fix / Workaround is applicableon this errata.A proposal for solving problems regarding the JTAG instruction IDCODE is presentedbelow.IDCODE masks data from TDI inputThe public but optional JTAG instruction IDCODE is not implemented correctlyaccording to IEEE1149.1; a logic one is scanned into the shift register instead of theTDI 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, anddata to succeeding devices are replaced by all-ones during Update-DR.If ATmega128 is the only device in the scan chain, the problem is not visible.Problem Fix / WorkaroundSelect the Device ID Register of the ATmega128 (Either by issuing the IDCODEinstruction or by entering the Test-Logic-Reset state of the TAP controller) to readout the contents of its Device ID Register and possibly data from succeedingdevices of the scan chain.
Note that data to succeeding devices cannot be enteredduring this scan, but data to preceding devices can. Issue the BYPASS instructionto the ATmega128 to select its Bypass Register while reading the Device ID Registers of preceding devices of the boundary scan chain. Never read data fromsucceeding devices in the boundary scan chain or upload data to the succeedingdevices while the Device ID Register is selected for the ATmega128. Note that theIDCODE instruction is the default instruction selected by the Test-Logic-Reset stateof the TAP-controller.Alternative Problem Fix / WorkaroundIf 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 can376ATmega1282467M–AVR–11/04ATmega128be connected in such way that the ATmega128 is the fist device in the chain.Update-DR will still not work for the succeeding devices in the boundary scan chainas long as IDCODE is present in the JTAG Instruction Register, but the Device IDregistered cannot be uploaded in any case.ATmega128 Rev.
F• Stabilizing time needed when changing XDIV Register• Stabilizing time needed when changing OSCCAL Register1. Stabilizing time needed when changing XDIV RegisterAfter increasing the source clock frequency more than 2% with settings in the XDIVregister, the device may execute some of the subsequent instructions incorrectly.Problem Fix / WorkaroundThe NOP instruction will always be executed correctly also right after a frequencychange. 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 instructions4.Set the I bit in SREGThis will ensure that all subsequent instructions will execute correctly.Assembly Code Example:CLIOUT; clear global interrupt enableXDIV, temp; set new prescale valueNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationNOP; no operationSEI; clear global interrupt enable2.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
