E2, IE850A
5. Notes on Usage
R20UT4140EJ0300 Rev.3.00
Page 33 of 41
Oct.09.20
5.4.17 Rewriting of on-chip flash memory (modifying the clock settings)
The debugger temporarily changes the clock settings to improve the speed of processing while the flash
memory is being rewritten* and restores the previous clock settings after this processing.
If the change in the clock frequency due to the debugger causes a problem, e.g. the frequency surpasses the
upper limit which was set by the clock monitor (CLMA), stop the modification of clock settings by using the
setting of the [Change the clock to flash writing] property (for CS+) or the FLASHCLOCK command or the -
noflashclock option (for MULTI).
Note: Rewriting of flash memory proceeds in response to any of the operations below.
•
Downloading to on-chip flash memory
•
Changes to on-chip flash memory by using the [Memory] panel or the [Disassemble] panel
•
Setting or cancellation of software breaks
•
Re-execution after a software break is encountered (including stepped execution)
5.4.18 Breaks during execution of code for making clock settings
The flash memory cannot be programmed if a break occurs while the MCU is running code written to memory
for making clock settings (setting of the main oscillator or PLL frequency divider and so on).
If you wish either of the following types of operation to proceed when a break has occurred during clock
settings, set [Change the clock to flash writing] in the [Property] panel to [No].
a. Any operation that involves programming of the flash memory (e.g. re-downloading)
b. Setting or deleting software breakpoints
Also, do not set software breakpoints within code for making clock settings.
5.4.19 Software break functions (RAM areas)
The software break function is implemented by replacing instructions. Thus, note that no break will occur if the
value at an address where a software break has been set is rewritten by a user program which is running. A
break will also not occur if a reset is generated during the execution of a user program, since RAM areas may
be initialized by hardware with certain settings.
5.4.20 Cases where no break occurs
No breaks occur when the CPU is in any of states listed below.
•
Initially stopped state
•
Reset state
5.4.21 Cautionary point regarding synchronous debugging mode
In the synchronous debugging mode, a break may occur for all CPUs. However, if any of CPUs is in the
initially stopped state, note that no break will occur. A breakpoint must be set in the program at a point after all
CPUs have been released from the initially stopped state. If you want to generate a break earlier than this, use
the asynchronous debugging mode. If you want to generate a break for a CPU in run mode with a device that
includes an initially stopped CPU or for a CPU in cyclic run mode during synchronous debugging, refer to
section 5.3.5, Executing a program in the initially stopped state after a reset.
