Block Guide — S12BDM V4

27

Differently from the normal bit transfer (where the host initiates the transmission), the serial interface

ACK handshake pulse is initiated by the target MCU by issuing a negedge in the BKGD pin. The hardware

handshake protocol in Figure 4-5 specifies the timing when the BKGD pin is being driven, so the host

should follow this timing constraint in order to avoid the risk of an electrical conflict in the BKGD pin.

NOTE:

The only place the BKGD pin can have an electrical conflict is when one side is

driving low and the other side is issuing a speedup pulse (high). Other “highs” are

pulled rather than driven. However, at low rates the time of the speedup pulse can

become lengthy and so the potential conflict time becomes longer as well.

The ACK handshake protocol does not support nested ACK pulses. If a BDM command is not

acknowledge by an ACK pulse, the host needs to abort the pending command first in order to be able to

issue a new BDM command. When the CPU enters WAIT or STOP while the host issues a command that

requires CPU execution (e.g., WRITE_BYTE), the target discards the incoming command due to the

WAIT or STOP being detected. Therefore, the command is not acknowledged by the target, which means

that the ACK pulse will not be issued in this case. After a certain time the host should decide to abort the

ACK sequence in order to be free to issue a new command. Therefore, the protocol should provide a

mechanism in which a command, and therefore a pending ACK, could be aborted.

NOTE:

Differently from a regular BDM command, the ACK pulse does not provide a time

out. This means that in the case of a WAIT or STOP instruction being executed, the

ACK would be prevented from being issued. If not aborted, the ACK would remain

pending indefinitely. See the handshake abort procedure described in

4.8 Hardware Handshake Abort Procedure.

4.8 Hardware Handshake Abort Procedure

The abort procedure is based on the SYNC command. In order to abort a command, which had not issued

the corresponding ACK pulse, the host controller should generate a low pulse in the BKGD pin by driving

it low for at least 128 serial clock cycles and then driving it high for one serial clock cycle, providing a

speedup pulse. By detecting this long low pulse in the BKGD pin, the target executes the SYNC protocol,

see 4.9 SYNC — Request Timed Reference Pulse, and assumes that the pending command and therefore

the related ACK pulse, are being aborted. Therefore, after the SYNC protocol has been completed the host

is free to issue new BDM commands.

Although it is not recommended, the host could abort a pending BDM command by issuing a low pulse in

the BKGD pin shorter than 128 serial clock cycles, which will not be interpreted as the SYNC command.

The ACK is actually aborted when a negedge is perceived by the target in the BKGD pin. The short abort

pulse should have at least 4 clock cycles keeping the BKGD pin low, in order to allow the negedge to be

detected by the target. In this case, the target will not execute the SYNC protocol but the pending command

will be aborted along with the ACK pulse. The potential problem with this abort procedure is when there

is a conflict between the ACK pulse and the short abort pulse. In this case, the target may not perceive the

abort pulse. The worst case is when the pending command is a read command (i.e., READ_BYTE). If the

abort pulse is not perceived by the target the host will attempt to send a new command after the abort pulse

was issued, while the target expects the host to retrieve the accessed memory byte. In this case, host and

target will run out of synchronism. However, if the command to be aborted is not a read command the short