There are two aspects of the EtherCAT IP operation that need to be considered from a debug emulation stand point.
- CPU Halted
Condition:
- CPU1: For any
operation from the EtherCAT IP that is based off an interrupt request,
it is quite important that this interrupt is marked as a real-time
interrupt and the debugger must be halted in RealTime mode. If the CPU
is halted without taking the above precaution, then the EtherCAT IP can
only be active for those parts where servicing the interrupt is not
required (For example, GPIO and SYNC0/1 output triggers can all function
unaffected).
- CPU2
Does not apply. CPU2 does not have
real-time debug and remains in halt mode until released by the run
command, regardless of interrupt request assertions.
- Debugger Writes/Reads of EtherCAT IP registers/memories Condition: The EtherCAT IP does not have any mechanism to identify a debug initiated read/write. Debug accesses to the registers or the ESC RAM can affect the state of the EtherCAT IP. This is addressed by the following:
- CPU1/CPU2: The ENABLE_DEBUG_ACCESS
bit must be set in the ESCSS Access Control Register to enable user
access to the ESC RAM and EtherCAT registers for the purpose of debug.
By default, this is disabled.