Tool News
 
 
 

Tool News

Products Info
Downloads
Tools FAQs
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

  1. At starting the MCU in the slave mode
  2. At setting software break points
  3. At controlling execution of a program that contains instructions for putting the MCU in the stand-by or the CPU sleep mode
  4. At executing emulation from reset vector

Description of Problems

Each problem is described bellow.

  1. 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".


  2. 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.

  3. 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.


  4. 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.





© 2008. Renesas Technology Corp., All rights reserved. Privacy | Legal