E2, IE850A
5. Notes on Usage
R20UT4140EJ0300 Rev.3.00
Page 27 of 41
Oct.09.20
5.3
Notes on differences in operation between the actual device and the emulator
5.3.1
Serial programming function
The serial programming function cannot be used with the emulator during debugging.
5.3.2
Current drawn
The target device draws more current when an emulator is connected than when it is not. That is, the target
device consumes more power while it is connected an emulator than while it is not, since the debugging circuit
is operating.
5.3.3
Multiplexed pins for the debugging interface
The multiplexed pin functions for the LPD interface, which is a debugging interface, cannot be used during
debugging.
5.3.4
Initialization of RAM areas
Be sure to initialize RAM from within the user program. If RAM is not initialized by the user program, a
program may operate incorrectly when the device is not connected to the emulator but operate normally when
the emulator is connected.
If any setting is made to initialize the RAM area when the emulator is connected, the debugger initializes local
RAM and cluster RAM areas to 0000 0000H. This leads to the following differences between the cases where
the emulator is and is not connected.
•
The initial values in the RAM area immediately after starting the emulator are different from the initial
values (which are undefined) of the device.
•
ECC errors due to non-initialization of the RAM are not detected with the emulator connected.
To emulate ECC errors, make the setting not to initialize the RAM area when the emulator is connected.
However, if the setting is for not initializing the RAM area when the emulator is connected, the following
functions are not available in the [Memory] window.
•
Downloading to on-chip flash memory
•
Changes to on-chip flash memory by using the [Memory] panel or the [Disassemble] panel
•
Setting of software breaks
ECC errors occur when the RAM area is displayed in the [Memory] window before the RAM area is initialized
by the user program.
5.3.5
Executing a program in the initially stopped state after a reset
When a reset is applied while a debugger is connected, it forcibly releases all CPUs from their initially stopped
states and places them in the break state, regardless of whether the debugger is in the synchronous
debugging mode or asynchronous debugging mode. If a program is executed in this state, note that the target
device may not operate normally.
Using the [Debug initial stop state] property (for CS+) and the FETCHSTOP command (for MULTI ) enables
execution of a program with the CPUs in the initially stopped state. For details of the procedure, refer to the
user’s manual for the debugger.
In addition, when an initially stopped core or a core on standby is to be debugged and operation that is close
to that of the actual device is required, set the [Debug the initial stop state and the standby mode] property (for
CS+) or the initstop boot-up option (for MULTI) to enable this. In this case, an initially stopped core will stay in
