up0019| Datasheet

Datasheet preview, take a look at Datasheets before downloading (Data Sheet is available on manufacturer site)

Product Update
UP001906-0607

Errata to eZ80190 Microprocessor

eZ80190 Microprocessor with Date Codes 0137 and Later
The errata listed in Table 1 highlights the issues and workaround (if available) related to eZ80190 product with package date codes 0137 and later. The issues are assembled after the 37th week of the year 2001.
Table 1. eZ80190 Microprocessor with Date Codes 0137 and Later No. Summary 1 Breaks during DEBUG mode may occur at incorrect addresses. This error does not affect the part during normal operation. SPI operating as a slave in multi-slave configuration can lose transmit data. Detailed Description During DEBUG mode using the ZiLOG Debug Interface (ZDI), all set break points occur as required. However, the CPU can break at program addresses which are not set in ZDI. This situation can occur when a data address is identical to a programmed break point address (for example, during a LD (HL),A instruction execution, where (HL) is identical to a break address). If this problem is encountered, the suggested workaround is to operate the eZ80190 Webserver at the lower limit of its voltage range (3.0 V) to reduce the false break point address match. If either of the SPI devices on the eZ80190 are configured as a slave device in a multi-slave system, the SPI data can be corrupted by transfers to and from the master and o
ther slaves sharing the same SPI pins. Even though the SS pin is High (not selecting the eZ80190's SPI device), the data is shifted into the SPI's receive buffer. This can overwrite any data that is placed in the SPI's transmit buffer by the eZ80 CPU in preparation for transmit out from the SPI slave. If the SPI devices should be used as slaves in multi-slave systems, the SCK input signal to the eZ80190 should be disabled externally when the SS signal is High. As a result, shifting in of data by the SPI slave receiver is prevented when not selected. A pulse on the SCL line prior to a START condition or after a STOP condition causes the I2C to lock up. This situation occurs regardless of the I2C control register ENAB settings (I2C_CTL). When this situation occurs, an I2C software reset does not unlock the I2C bus. Workarounds If a lock occurs after the SCL line is released, another device on the I2C bus can issue a Stop condition by pulsing the SDA line. As a result, the I2C should unlock. Another option is
to initiate an overall SYSTEM RESET of the eZ80190 in order to reset the I2C block.

A pulse on the SCL line when the I2C bus is idle and the SDA line is held High causes the I2C to lock up.