 |
|
 |
MESC TOOL NEWS:
MESCT-M32000T-2MB-E-971116D
|
M32R/D Emulator Precaution
|
Please care about the problems described bellow which occur in certain conditions when using M32R/D series emulators M32000T-2MB-E, M32000T-2MB, and M32000T-1MB.
Problems
- At starting the MCU in the slave mode
- At setting software break points
- At controlling execution of a program that contains instructions for
putting the MCU in the stand-by or the CPU sleep mode
- At executing emulation from reset vector
Description of Problems
Each problem is described bellow.
- At starting the MCU in the slave mode
When the M32R/D MCU is in the slave mode, it can be started, after reset of
the MCU, by the generation of either an external interrupt request (/INT) or
a system break interrupt request (/SBI). However, when an M32R/D
emulator is used, a /SBI request cannot start the MCU. This error will occur
if the following three conditions are satisfied at the same time;
- an M32R/D emulator is used,
- the MCU is in the slave mode, and
- system break interrupt /SBI is used to start the MCU after reset.
This error does not occur when no M32R/D emulator is used, or external
interrupt request /INT is used to start the MCU.
[Solution]
When an M32R/D emulator is used under such conditions as this error
occurs, the MCU can be started by the following sequence:
- assert /SBI after reset of MCU,
- negate /SBI temporarily, and then
- assert /SBI again after 5 ms or more has elapsed.
However, tracing function is subject to the following limitation in this case.
[Limitation]
Tracing by specifying external bus sampling sources for each external clock
cannot be performed. This tracing corresponds to the tracing function
performed when Trace=ON, Trace PC=OFF, and Sample=Clock are selected
in Debugger Menu "Options>Trace Setup".
- At setting a software break point
The errors described bellow occur if, in user space, a software break point is
set within logical space other than the currently working logical address
space, that is, in the ghost area of the currently working logical space, and
then the break is executed.
- Even if set in a ghost area, a break point is undesirably mirrored in the
currently working logical space, and a break hit that has not been specified
is generated when the instruction at this mirror address is executed. (For
instance, when a break point is set at h'01100000 in the ghost area, this
phenomenon takes place if the instruction at h'00100000 is executed.) In this
case an error message is displayed on the debugger window.
- Furthermore, if several break points are set at the physically identical
addresses by using incorrect setting of break points in the ghost area, and
then these breaks are executed, the instruction codes at these addresses are
replaced by the incorrect codes. (For instance, when break points are set at
(1) occurs if the instruction at h'00100000 is executed, and at the same time
the instruction code at h'00100000 is replaced by the incorrect one.) At this
time the same error message as in (1) is displayed on the debugger window if
several break points are all set in the ghost area; however, if correct break
addresses are set simultaneously, the error message does not appear.
In either case, incorrect instruction codes replace the correct ones.
[Solution]
These errors can be avoided by not setting break points in the ghost area.
- At controlling execution of a program that contains instructions for
putting the MCU in the stand-by or the CPU sleep mode
-
When a break point is set in a 4-byte address in alignment containing the
transfer instruction that is loaded to the MRMR register to put the MCU in
the stand-by or the CPU sleep mode, or the program is executed up to the
above 4-byte address to go temporarily to a break point by the Come menu
and then re-executed, the subsequent operation will not be guaranteed.
- If the transfer instruction described above is executed by the Step or
Amstep menu, or executed by the Go menu when PC trace is designated, the
subsequent operation will not be guaranteed.
[Solution]
If the operations described above in (1) and (2) have been performed, again
execute emulation after resetting the MCU with the File>CPU Reset menu.
If the File>CPU Reset menu is not effective, restart the emulator.
- At executing emulation from reset vector
An error occurs if the Reset&Go menu is used to execute emulation from
MCU Reset.
After executing the Reset&Go menu, the emulator transitions to the state of
waiting a /RESET signal to the MCU. However, if a Stop instruction is
issued at this time, the values loaded in SPU, SPI, and all the other general
purpose registers are changed to incorrect ones.
[Solution]
If the above operation has been performed, reload the correct values into
SPU, SPI, and all the other general purpose registers.
|
 |