The watchdog timer refresh is generated in places where it is not expected and then the Communication Timeout Error occurs (when debugging M16C, M32C).
There are two possible causes:
- When you are not using the watchdog timer but the [Debugging of program that uses WDT ] box is selected (ON) in the Firmware Assignment tab in the E8/E8a Emulator Settings dialog.
To debug a program that does not use the watchdog timer, make sure this box is not selected (OFF).
- When E8/E8a Usage Restrictions Apply
When using E8/E8a to debug a program that uses the watchdog timer, the [Debugging of program that uses WDT ] box in the Firmware Assignment tab in the E8/E8a Emulator Settings dialog must be selected (ON).
To make sure that a watchdog timer overflow does not occur while the user program is stopped (during break), the E8/E8a firmware periodically refreshes the watchdog timer (only during program breaks).
However, in M32C and M16C watchdog timer specifications, "refresh" equals "start WDT." Regardless of whether the watchdog timer has been started or not in the user program, it will start automatically.
Refer to the following program as an example.
Loop process (2)
Watchdog Timer reset (1)
Start is the start address after the MCU reset occurs. In this case, based on the MCU specification, the watchdog timer starts operating when the watchdog timer reset (1) is processed. However, when using E8/E8a to debug the watchdog timer, the timer will start operating when the program starts (3).
So, if you have a loop process such as that indicated by (2) above, a watchdog timer reset is occurred before (1) is reached, thus generating a Communication Timeout Error.
If this is the problem you are experiencing, please input a watchdog timer reset process before (1) above, but only when debugging.