Hitex Germany. Application Note. ARM Debugging - Startup Behaviour after Reset

Transcription

1 Hitex Germany Head Quarters Greschbachstr Karlsruhe Germany Fax WEB: Hitex UK Warwick University Science Park Coventry CV47EZ United Kingdom Fax WEB: Hitex USA 2062 Business Center Drive Suite 230 Irvine, CA U.S.A HITEX (US only) Fax WEB: Application Note ARM Debugging - Startup Behaviour after Reset This documentation gives a short introduction to the EmbeddedICE Macrocell module and shows how to configure the EmbeddedICE Logic and the startup and reset behaviour of an ARM core using a Hitex debugger and its user interface HiTOP. Code examples and hints for a proper start are given in the final chapter. Architecture: ARM Author: Thomas Dirsch /Hitex GmbH Revision: 01/ Copyright Hitex Development Tools GmbH All rights reserved. No part of this document may be copied or reproduced in any form or by any means without prior written consent of Hitex Development Tools. Hitex Development Tools retains the right to make changes to these specifications at any time, without notice. Hitex Development Tools makes no commitment to update nor to keep current the information contained in this document. Hitex Development Tools makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hitex Development Tools assumes no responsibility for any errors that may appear in this document. DProbe, Hitex, HiTOP, Tanto, and Tantino are trademarks of Hitex Development Tools. All trademarks of other companies used in this document refer exclusively to the products of these companies. ApplicationNote.dot - 11/

2 Preface In order to keep you up-to-date with the latest developments on our products, we provide Application Notes containing additional topics, special hints, examples and detailed procedures etc. For more information on the current software and hardware revisions, as well as our update service, please contact or Contents 1 The EmbeddedICE Macrocell 3 2 Differences in Implementation 4 3 Hitex Solution HiTOP Configuration with both Reset Pins HiTOP Configuration with nsrst Reset Pin only 8 4 Hints for a Proper Start 10 Copyright 2008 Hitex Development Tools GmbH Page 2/10

3 1 The EmbeddedICE Macrocell The EmbeddedICE macrocell module is the additional hardware provided by debuggable ARM processors to aid debugging. It provides on-chip debug support for ARM cores, e.g. the ARM7TDMI. A request on the debug interfaces through a debugger such as TantinoARM7/9 program the EmbeddedICE logic to force the ARM processor into debug state. The events that activate debugging are: Breakpoints (instruction fetch), Watchpoints (data access), External debug requests. The EmbeddedICE Logic is programmed serially using the TAP controller. The following figure illustrates the relationship between the processor core, the EmbeddedICE Logic and the TAP controller. Only the JTAG-Port signals are shown: Fig. 1 Relationship between the processor core, EmbeddedICE Logic and the TAP controller Copyright 2008 Hitex Development Tools GmbH Page 3/10

4 2 Differences in Implementation The chip manufactures implement the ARM core and the JTAG connection in different ways. For the JTAG interface most of the signals are essential, some not (e.g. the ntrst and RTCK signal), but for the debugging behaviour after reset, the implementation of the ntrst signal is important. After reset, due to the nature of the ARM core, the core starts always to execute the application. Depending on the RESET signal, the EmbeddedICE Logic is also reset and will lose all programmed breakpoints and watchpoints. The core executes the application until the debugger sends a JTAG command to stop it. The code, which is executed in the meantime, will normally initialize the hardware first. Due to a possible mistake or a bug in the code, the worse case could be that the JTAG connection fails. However, the core starts and the application will first initialize the hardware and peripherals of the chip. With script files or manually, the program counter is set back to the reset entry point 0x to start debugging from reset. This could be a problem, because the application will re-initialize the hardware and peripherals. As an effect, some peripherals could not operate properly. Fig. 1 on p. 3 illustrates the implementation of the debug unit. Two reset signals are available on the JTAG port: nsrst Target System Reset, to reset the system, including the ARM core ntrst Test Reset, to reset the TAP controller and EmbeddedICE Logic Some ARM core implementations contain only the nsrst reset signal and are connected internally on-chip with ntrst. This is mostly done to save one pin. The disadvantage is that every reset will also reset the TAP controller and the EmbeddedICE Logic. The ARM core starts the application with all possible consequences. If both reset signals are connected, a System Reset will not reset the TAP controller and the EmbeddedICE Logic. The EmbeddedICE Logic will still hold the information and a possible programmed breakpoint will stop the ARM core. When a reset is performed, the debugger defines a temporary breakpoint at the address 0x and the ARM core will stop after reset at this start address. Copyright 2008 Hitex Development Tools GmbH Page 4/10

5 3 Hitex Solution With HiTOP and the Hitex ARM debugger, a definition for the reset behaviour is possible. Using the Project Settings dialog, HiTOP can be configured for several reset features: Time (in ms) how long a reset command will hold active the reset signal nsrst. Time to wait (in ms) until the debugger will stop the core after reset is inactive. Availability of the reset signal ntrst. Definition if nsrst is also to reset the TAP controller. All these settings are done in the Project settings dialog: Project > Settings > Processor Settings > Pins, and Project > Settings > Target Settings > Target Reset If ntrst is available and a reset command is performed, HiTOP will program a temporary breakpoint at address 0x and reset the system with the nsrst signal. The core will stop at address 0x and no application is executed. Debugging starts from reset then. Copyright 2008 Hitex Development Tools GmbH Page 5/10

6 3.1 HiTOP Configuration with both Reset Pins First, the availability of the ntrst pin should be configured. According to the physical connection of the ntrst pin, the debugger must know the availability of the ntrst pin to use the correct reset behaviour. The TAP Reset Pin setting must be defined as "present", if it is available. Proceed as follows: Open the Project > Settings > Processor Settings > Pins dialog and select: TAP Reset Pin = present Copyright 2008 Hitex Development Tools GmbH Page 6/10

7 Next, the internal reset behaviour and the timing of the reset signal should be configured. Setting the "no" option for Target Reset resets TAP Controller? and the availability of the ntrst pin, will program a temporary breakpoint at address 0x before a reset is performed. When the reset command is performed, the controller stops at the reset entry point. Proceed as follows: Open the Project > Settings > Target Settings > Target Reset dialog and select: Target Reset resets TAP Controller? = no Minimum Target Reset Duration will specify the active time for the reset signal when a reset command is performed. Maximum Target Startup Time after Reset will define the time the debugger will wait until reset gets inactive to stop the core by a JTAG command. With availability of ntrst, this setting can be ignored. Copyright 2008 Hitex Development Tools GmbH Page 7/10

8 3.2 HiTOP Configuration with nsrst Reset Pin only First, the availability of the ntrst pin should be configured. According to the physical connection of the ntrst pin, the debugger must know the availability of the ntrst pin to use the correct reset behaviour. The TAP Reset Pin setting must be defined as "missing", if it is not available. Proceed as follows: Open the Project > Settings > Processor Settings > Pins dialog and select: TAP Reset Pin = missing Copyright 2008 Hitex Development Tools GmbH Page 8/10

9 Next the internal reset behaviour and the timing of the reset signal must be configured. With the setting Target Reset resets TAP Controller?=yes, a reset command (RESET TARGET) will not generate a RESET signal at the ntrst pin, but a reset command is sent via JTAG, which will generate the RESET signal internally for the TAP controller. However, with one reset pin only, the TAP controller and EmbeddedICE macrocell will also be reset and will lose all breakpoint information. Minimum Target Reset Duration will specify the active time for the reset signal when a reset command is performed. Maximum Target Startup Time after Reset will define the time the debugger will wait until reset gets inactive to stop the core by a JTAG command. Depending on the hardware, a short time is recommended so that the debugger stops the core quickly after reset. Proceed as follows: Open the Project > Settings > Target Settings > Target Reset dialog and select: Target Reset resets TAP Controller? = yes Maximum Target Startup Time after Reset = 50ms Copyright 2008 Hitex Development Tools GmbH Page 9/10

10 4 Hints for a Proper Start If ntrst is available and the HiTOP configuration is done as described above (see chapter HiTOP Configuration with both Reset Pins), debugging from reset is possible. Otherwise, the ARM core starts and after effects are possible, when the program counter is set back to the reset entry address. In the following we will show an easy solution to avoid these effects. A short delay loop is to be added in the startup file before any initialization is made. Code Example with GNU in the Assembler File "Startup.s" DelayMax:.word 0x1000 # Delay for emulator ldr r1, DelayMax mov r0, #0 DelayLoop: add r0, r0, #1 cmp r0, r1 blo DelayLoop Example using a Macro # # startup delay # use this macro if you are working with a debugger # the startup delay avoid problems while # the application starts before the debug interface # becomes controlled by the debugger # # a good choice for the delay value is # cpu clock / 100 with ATMEL controllers # cpu clock / 40 with Philips controllers.macro StartupDelay delay_value ldr R1, =\delay_value ldr R2, =0 StartDelay: sub R1, R1, #1 cmp R1, R2 bhi StartDelay.endm Use the macro immediately after the reset entry point: StartupDelay By means of a compiler option, the macro (and the loop) can be defined for the debug session only and may be removed for the release version. In conjunction with a time definition for the HiTOP setting Maximum Target Startup Time after Reset, the loop can be limited to a short execution time. Copyright 2008 Hitex Development Tools GmbH Page 10/10