AN2099/0405 1/8 rev. 1 AN2099 application note guidelines for connecting via jtag protocol to the str71x microcontroller introduction this application note provides guidelines on how to connect a host debugger to a target str71x board via a jtag protocol converter, taking into account the internal features of the str71x microcontroller product family. this document is targeted for third party tool suppliers or application engineers interested in connecting to the str71x using the jtag connect or. for basic references on the jtag tar- geted for the arm core, please refer to the arm7tdmi technical reference manual figure 1. hardware setup example str71x board host pc power supply jtag connector jtag protocol converter 1
2/8 guidelines for connecting via jtag prot ocol to the str71x microcontroller 1 overview one of the features of the str71x is to allow the user to boot an application from internal ram, which could be used for debugging purposes. however, that system configuration may potentially result in a hang-up when the debugger attempts to initiate the jtag communica- tion with the microcontroller. this could be ca used by some random code in ram that could set the str71x in an unpredictable mode and prevent jtag connection to the target. section 2 of this application note describes the inherent features of the str71x affecting the jtag connection. section 3 presents a set of solutions for overcoming all the connection is- sues. finally, section 4 , gives a detailed description of the jtag connection sequence from the point of view of the jtag protocol converter. 2 parameters affect ing jtag connection this section covers all the known par ameters that affect the jtag connection. 2.1 delay for flash initialization one aspect to be taken into account is the time for the internal str71x flash initialization fol- lowing a system reset. the flash initialization holds an internal signal controlling the arm jtag reset pin in an undefined state for a deterministic amount of time. this is explained in detail in section 3.2. 2.2 reset signals connected having both system reset and the jtag reset connected to the same signal will prevent con- nection since the system reset has to be asse rted during the jtag communication protocol and released before the start of the application. therefore having both pins tied to the same signal will prevent any jtag communication with the embedded ice registers. 2.3 putting the str71x cpu in halt mode the halt mode of the str71x cpu is used for debug purposes. this means that once debug state is initiated, the core is stopped and isolated from the rest of the system until the de- bugger restores the system state. the str71x can only switch to debug state by switching from the main cpu clock (mclk) to the arm jtag clock (dclk) controlled by the debugger. the str71x cpu enters halt mode on the next falling edge of mclk after dbgrq is asserted. therefore mclk has to be running internally to be able to connect via jtag. for this reason, it is not possible to connect via jtag when the str71x is in wfi (wait for interrupt) mode or stop mode.
3/8 guidelines for connecting via jtag pr otocol to the str71x microcontroller 2.4 connection sequence from standby mode when the core is in standby, the core and peripherals are powered down, therefore a straight connection to the jtag is not possible if the wakeup logic or system reset has not been trig- gered. to exit standby, the wakeup sequence needs to be run to switch the main voltage reg- ulator (which supplies the core and on-chip peripherals) back on to its nominal value. the wakeup procedure triggers a system reset sequence. 2.5 connection when code is executing from str71x memory attempting to connect while the str71x is ex ecuting code from its memory is not recom- mended as this is not considered as a robust solution. for example, the target could have al- ready executed the code to put the str71x in standby mode and therefore any subsequent attempt might fail. 3 connection methods 3.1 boot from flash, copy to ram one way to bypass the possibility of hitting a random instruction in ram that might put the system in an undefined state is to boot an application from address 0x0 in flash which then copies an image to internal ram and executes from it. this will prevent any illegal or un- wanted instruction being hit since the flash is manufactured with known data contents, and this is also the case when a flash sector is er ased. this eliminates th e possibility of hitting a random code when the application is booted from internal ram. 3.2 flash initialization as mentioned in section 2 , no jtag connection to the target is possible during the flash ini- tialization phase, as described in figure 2. the jtag_en signal is asserted and might reset the arm tap. taking into account the flash initialization procedure, the jtag connection sequence can not be initiated before phase 3 described in figure 2.
4/8 guidelines for connecting via jtag prot ocol to the str71x microcontroller figure 2. str71x reset sequence the reset sequence is divided into 6 phases: 1. str71x reset: the whole device is under reset. 2. clock stabilization: the cpu and the flash are kept under reset for the internal clock stabilization. 3&4. flash initialization: the flash is in itialized internally keeping the cpu under reset. this period varies as it is clocked by an embedded rc oscillator. the 2048tck period is set to allow enough time to the flash to be initialized with f ck =16mhz. 5. clock start-up: mclk is supplied to the various internal blocks of the device while cpu and peripherals are kept under reset. 6. user application execution: the user application is executed from address 0x00000000 by the cpu. 3.3 standby program to illustrate the connection sequence in standby mode, we can use a piece of code, which we call the standby program, that puts the core in standby by setting the pwrdwn bit in the power control register of the prccu. we place this code in internal flash for execution. this is the worst case scenario for the debugger connecting to the target since once the cpu starts to execute the code at address 0x0, the core enters standby mode. therefore this is a perfect test for the jtag connection sequence since the only way to con- nect from standby is to perform a system reset, then after the flash initialization phase (phase ck rstin jtag_en rstarm mclk phase 255t ck 2048t ck ~20s 16t ck 23456 1
5/8 guidelines for connecting via jtag pr otocol 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 exec uted 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 communicati on 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.
6/8 guidelines for connecting via jtag prot ocol to the str71x microcontroller ? the ice debug control comms register is read (v ia scan chain2). this register is read in order to determine whether the processor or the debugge r can write to this register to initiate the handshaking dbgrq/dbgack. ? the ice debug status register is read to check dbgack . this is to make sure the core is not already halted in debug mode. ? dbgack is set to 1, the system is in debug mode. ? the first instructions are passed to the core via scan chain 1 in debug mode. ? dbgack is deasserted by writing to the ice debug control register. ? read back dbgack = 0 from the ice debug status register. ? njtrst and sysnrst are asserted, tap is in restart (exit from debug mode). ? sysnrst is deasserted. 4.2 connection handshake protocol this sequence is mandatory for connecting to the str71x. this section could be executed after the 2048tck periods as described in figure 2. the connection sequence: ? the debugger halts the cpu by asserting dbgrq internally and waits for dbgack signal from the cpu. ? instructions and data are passed to the core via the embedded ice scan chain 1, and the dbgrq/dbgack protocol is controlled via scan chain 2. ? tap goes to soft reset (tms=1 for 5 tck puls es) to make sure the jtag connection starts from a reset state ? *scan chain 2 (to access ice register) is selected to write to the ice debug control register: dbgrq is asserted to the cpu in order to put the cpu in debug mode. then the ice debug status register is read in a loop until dgback is asserted by the cpu. a tap soft reset is performed in every loop iteration. ? the status register is read, and dbgack is asserted, the core has entered debug state. as described in section 2.3 , the cpu enters halt mode. ? once in debug state, the cpu needs to be isolated from the rest of the system so that the debugger is in full control. system peripherals need to be aware that the core is in debug state, the core is clocked by dck instead of mclk, and all the interrupts to the core are dis- abled. this is done by forcing bit 0 and bit 2 to logic 1 (dgback and int) in the ice debug control register, and reading back the ice status register to make sure these signals have been asserted. ? the core in debug state shifts instructions/data using scan chain 1 from which point we can execute instructions to the core, read/write register values in debug state.
7/8 guidelines for connecting via jtag pr otocol to the str71x microcontroller 4.3 switching from debug to system mode this section is not mandatory, but explains when the debugger needs to access the system memory, this can be done by executing instructions temporarily in run mode. ? the ice debug status register is read via scan chain2 to make sure we are still in debug mode by checking dbgack. ? then switch back to scan chain1. in shifting data and the breakpoint bit into the scan chains, the brkpt bit value is set to logic ?0? ? then the brkpt bit is set to logic "1" in order to execute an instruction at system speed re- quested by the debugger, to return to system s tate ( to access system memory for example that needs to be performed at system speed). this is done by performing restart to exit debug state to execute the instruction at system speed (mclk), then goes back to debug state once the execution has ended (the core is then clocked with dclk). ? the ice debug status register is read to make sure the system has changed back to debug mode by checking dbgack. ? from which point we can execute instructions to the core in debug state using scan chain1.
8/8 guidelines for connecting via jtag prot ocol to the str71x microcontroller ?the present note which is for guidance only aims at providing customers with information regarding their products in order for them to save time. as a result, stmicroelectronics shall not be held liable for any direct, indirect or consequential damages with respect to any claims arising from the content of such a note and/or the use made by customers of the information contained herein in connection with their products.? information furnished is believed to be accurate and reliable. however, stmicroelectronics assumes no responsibility for the co nsequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use. no license is granted by implication or otherwise under any patent or patent rights of stmicroelectronics. specifications mentioned in this publicati on are subject to change without notice. this publication supersedes and replaces all information previously supplied. stmicroelectronics prod ucts are not authorized for use as critical components in life support devices or systems without express written approval of stmicroelectro nics. the st logo is a registered trademark of stmicroelectronics. all other names are the property of their respective owners ? 2005 stmicroelectronics - all rights reserved stmicroelectronics group of companies australia ? belgium - brazil - canada - china ? czech republic - finland - france - germany - hong kong - india - israel - ital y - japan - malaysia - malta - morocco - singapore - spain - sweden - switzerland - united kingdom - united states of america www.st.com
|
