5/8

Guidelines for connecting via JTAG protocol to the STR71x microcontroller

3 in Figure 2.) initiate connection before the code starts executing from memory. The de-

bugger should connect before any code is executed from memory, because as seen previ-

ously, random code in RAM could result in undefined behaviour by the core. The Standby pro-

gram is as follows:

*(unsigned short *)0xa0000054 = 0x8000;

*(unsigned short *)0xa0000054 = 0x8040;

for (;;) ;

3.4 CONCLUSION

Connection could be performed as soon as possible:

– after flash initialization

– when MCLK is running internally

– before the code execution starts.

The host debugger should assert DBGRQ after the flash initialization phase and needs to wait

2048 TCK periods before asserting DBGACK, which puts the CPU in Halt mode. This puts the

host debugger in full control of the STR71x CPU before it executes any code from memory.

4 JTAG CONNECTION SEQUENCE EXAMPLE

This section describes the JTAG communication output from the JTAG protocol converter at

the time when the connection is performed on the target. The sequence is analysed from the

first JTAG reset until the system is in debug mode and when the first system accesses are ex-

ecuted by the target, initiated by the debugger. The JTAG communication protocol sequence

is described in chronological order

4.1 TAP IDCODE AND HALT MODE CHECK

This section is optional since it is not a request from the debugger to connect to the CPU , it is

a way for the debugger to identify the CPU by reading back the TAP ID code of the device or

checking whether the device is already in debug mode.

– NJTRST goes out of reset.

– 1 Tck pulse to put the TAP in IDLE.

– TAP is in IDCODE and data is shifted out of TDO This is the first check by the debugger to

identify the device. If the idcode of the device can not be read, the debugger can stop the

connection sequence by displaying a error message in a popup window.