C515C-8EM

Microcontrollers
Errata Sheet
9 July 2001 / Release 1.4
Device:
Stepping Code / Marking:
Package:
C515C-8E
BB
P-MQFP-80
This Errata Sheet describes the deviations from the current user documentation. The
classification and numbering system is module oriented in a continual ascending sequence
over several derivatives, as well already solved deviations are included. So gaps inside this
enumeration could occur.
The current documentation is: C515C User's Manual 11.97
C515C Data Sheet 07.99
Instruction Set Manual 05.98
Note: Devices marked with EES- or ES are engineering samples which may not be
completely tested in all functional and electrical characteristics, therefore they should
be used for evaluation only.
The specific test conditions for EES and ES are documented in a separate Status Sheet.
Change summary to last Errata Sheet Rel. 1.3:
•
Added new item numbered OTP.2.
Errata Sheet, C515C-8E, Step BB, Release 1.4, WSM
- 1 of 6 –
Functional Problems:
CAN.2: Unexpected Remote Frame Transmission
The on-chip CAN module may send an unexpected remote frame with the identifier=0, when a
pending transmit request of a message object is disabled by software.
There are three possibilities to disable a pending transmit request of a message object (n=1..14):
•
Set CPUUPDn element
•
Reset TXRQn element
•
Reset MSGVALn element
Either of these actions will prevent further transmissions of message object n.
The symptom described above occurs when the CPU accesses CPUUPD, TXRQ or MSGVAL, while
the pending transmit request of the corresponding message object is transferred to the CAN state
machine (just before start of frame transmission). At this particular time the transmit request is
transferred to the CAN state machine before the CPU prevents transmission. In this case the transmit
request is still accepted from the CAN state machine. However the transfer of the identifier, the data
length code and the data of the corresponding message object is prevented. Then the pre-charge
values of the internal “hidden buffer” are transmitted instead, this causes to a remote frame
transmission with identifier=0 (11 bit) and data length code=0.
This behavior occurs only when the transmit request of message object n is pending and the transmit
requests of other message objects are not active (single transmit request).
If this remote frame loses arbitration (to a data frame with identifier=0) or if it is disturbed by an error
frame, it is not retransmitted.
Effects to other CAN nodes in the network
The effect leads to delays of other pending messages in the CAN network due to the high priority of
the Remote Frame. Furthermore the unexpected remote frame can trigger other data frames
depending on the CAN node’s configuration.
Workaround:
1.
The behavior can be avoided if a message object is not updated by software when a transmission
of the corresponding message object is pending (TXRQ element is set) and the CAN module is
active (INIT = 0). If a re-transmission of a message (e.g. after lost arbitration or after the
occurrence of an error frame) needs to be cancelled, the TXRQ element should be cleared by
software as soon as NEWDAT is reset from the CAN module.
Errata Sheet, C515C-8E, Step BB, Release 1.4, WSM
- 2 of 6 –
2.
The nodes in the CAN system ignore the remote frame with the identifier=0 and no data frame is
triggered by this remote frame.
CAN.3: Description in User's Manual regarding the reception of remote frames and the
data length code (DLC) field is incorrect
It is inaccurately described in the User's Manual on page 6-94 under 'Arbitration Registers' that 'When
the CAN controller stores a remote frame, only the data length code is stored into the corresponding
message object'.
The correct should be that the DLC field remains unchanged in the receiving
message object, and that the CPU has the responsibility to define the DLC of the answering data
frame.
This correction will be updated to the future versions of the User's Manuals.
Workaround:
Not applicable.
CAN.4: Flowchart sequence in figure in User's Manual regarding Micro-controller
handling of the Last Message Object is partly incorrect
For the software flowchart figure 6-48 in User's Manual 11.97, the correct would be to first 'process
message contents' and then to 'clear bit NEWDAT'.
process message contents
NEWDAT: = 0
This correction will be updated to the future versions of the User's Manuals.
Workaround:
Not applicable.
Errata Sheet, C515C-8E, Step BB, Release 1.4, WSM
- 3 of 6 –
CAN.5: Description in User's Manual section 6.5.5 regarding the Configuration of the
Bit Timing is partly incorrect
As described for the CAN Bit Timing Register High BTR1, the minimum total time requirement for
segment 1 and segment 2 is as follows:
tTSeg1 ≥ 3 x tq,
tTSeg2 ≥ 2 x tq.
The total bit time remains at (t TSeg1 + t TSeg2 ≥ 7 x tq).
This correction will be updated to the future versions of the User's Manuals.
Workaround:
Not applicable.
WDT.1: Watchdog Timer is not halted in idle mode
The Watchdog Timer (WDT) is not halted in the idle mode as defined. However, during the idle mode,
an overflow condition of the WDT does not initiate an internal reset. In such a case the WDT starts a
new count sequence.
Workaround:
1.
Do not use the WDT function in combination with the idle mode.
2.
In case of WDT is running before entry into idle mode, to avoid a WDT initiated reset upon exit of
the idle mode, the following methods can be used.
(A) The WDT is refreshed immediately upon exit from idle mode.
(B) A timed interrupt can be used to exit the idle mode before the WDT reaches the counter state
7FFCh.
This can be achieved by using Timer 0, 1 or 2.
This timer can be programmed to
generate an interrupt at a WDT counter state prior to overflow, for e.g., at 7F00h. Prior to entering
idle mode, the WDT can be refreshed and the timer 0, 1or 2 can be started immediately to
synchronize the WDT. In the interrupt service routine of the Timer 0, 1 or 2, the WDT must be
refreshed. If required, idle mode could be entered again.
Errata Sheet, C515C-8E, Step BB, Release 1.4, WSM
- 4 of 6 –
OTP.1: ROM Verification Mode 2 and verification error signaling at Port 3.5
P3.5 does not remain at "0" permanently after detecting a verify error. It will return to "1" when a block
of 16 bytes is equal to the internal memory contents, i.e. the verify procedure for these 16 bytes is
passed.
Also, the last block of 16 bytes will always return verification error in the ROM Verification Mode 2.
Workaround:
None.
OTP.2: OTP module may fail under special conditions, leading to undefined operation
The OTP module may malfunction, causing the chip to enter an undefined state with unsteady
operation, if there is a remaining voltage at the VDD pin before powering up. The critical remaining
voltage is approximately 100-400mV. The undefined state can only be left by a complete power off
(V DD =0V) and not by any RESET-source (e.g. hardware reset, WDT-reset). The problem is due to
variation in technology and manufacturing parameters.
Workaround:
The device should always be powered up from VDD =0V, ensuring that there is no voltage at any pins
which leads to a remaining voltage level at VDD pin (coupling over the ESD-structure).
Deviation from Electrical- and Timing Specification:
DC.3: VIH minimum on EA pin does not meet the specification values
The VIH min voltage on pin EA does not meet the specified values:
VIH min for EA pin is (0.6 • VDD )V, instead of (0.2 • VDD + 0.9)V.
The new value will be worked into future documentation.
DC.4: VDD is valid for a smaller range than specified on documents
VDD is valid in the range from 4.5V to 5.5V at all specified temperatures, instead of 4.25V to 5.5V as
specified on the documents. This smaller range is effective on devices with date code 0115.
Errata Sheet, C515C-8E, Step BB, Release 1.4, WSM
- 5 of 6 –
History List (since last CPU Step ES-BA)
Functional Problems
Functional
Short Description
Fixed
Problem
CAN.2
Unexpected Remote Frame Transmission
CAN.3
Description in User's Manual regarding the reception of remote frames and
the data length code (DLC) field is incorrect
CAN.4
Flowchart sequence in figure in User's Manual regarding Micro-controller
handling of the Last Message Object is partly incorrect
CAN.5
Description in User's Manual section 6.5.5 regarding the Configuration of the
Bit Timing is partly incorrect
WDT.1
Watchdog Timer is not halted in idle mode
OTP.1
ROM Verification Mode 2 and verification error signaling at Port 3.5
OTP.2
OTP module may fail under special conditions, leading to undefined
operation
AC/DC Deviations
AC/DC
Short Description
Fixed
DC.1
Power supply current in Power Down Modes
step BB
DC.2
3 LSB total unadjusted error (TUE) of A/D converter
step BB
DC.3
VIH minimum on EA pin does not meet the specification values
DC.4
VDD is valid for a smaller range than specified on documents
Deviation
Application Support Group, Singapore
Errata Sheet, C515C-8E, Step BB, Release 1.4, WSM
- 6 of 6 –
Similar pages