|
If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
Datasheet File OCR Text: |
1/12 october 2001 the first part of this document describes the st120 trap servicing.the second part presents the implemented software to deal with a trap event. finally, the third part provides the user with a way to debug his code when a trap occurs during the execution of a program. customer support for any questions concerning the st120 dsp please contact our experienced staff of engineers at the following address: st100.support@st.com. AN1480 application note handling traps with the st120 core by batrice balay
AN1480 - application note 2/12 table of contents page 1 st120 trap servicing .......................................................................................... 3 1.1 introduction ........................................................................................................ 3 1.2 trap sequence overview ................................................................................ 3 1.3 hardware trap sequence ............................................................................... 3 1.4 software trap sequence ............................................................................... 4 1.5 trap vector address ........................................................................................ 5 2 software implementation for trap handlers ...................................... 6 2.1 the trap vector table ..................................................................................... 6 2.2 trap handlers ..................................................................................................... 7 2.3 default trap handlers .................................................................................... 7 3 how to get detailed trap handlers........................................................... 9 3.1 data related to a trap .................................................................................... 9 3.2 the trap handler routines ............................................................................ 9 3.3 a way to use the function trap_print ...................................................... 10 AN1480 - application note 3/12 1 - st120 trap servicing 1.1 - introduction the primary goal of traps is to inform the user that a problem occurs during the execution of a program and requires to be fixed. two kinds of traps can be distinguished : hardware traps and software traps. software traps are generated by the instruction trap. this instruction is available in gp16 and gp32 instruction modes. hardware traps occur when the execution of a program has caused some exceptional conditions which prevent the program from continuing its normal execution. hardware traps are driven by the following hardware elements : the st120 core, the dmc (data memory controller) and the pmc (program memory controller). hardware traps are then subdivided into 2 categories: precise and non-precise traps. precise hardware trap : precise trapping implies that all the instructions prior to the trapped instruction have completed and that the trap instruction and none of its successors been have executed. the core and the pmc produce precise traps. imprecise hardware trap : non-precise trapping implies that all the instructions prior to the trapped instruction have completed and that the trap instruction and potentially some of its successors may have been executed. by the nature of the st120 pipeline, all data memory accesses are dealt with the bottom of the pipeline and so errors associated with those accesses can not be precise. therefore, the dmc produces non-precise traps. 1.2 - trap sequence overview the management of traps is performed though the use of exceptions vectors. these vectors are located at the start of the memory address space. the trap vector address is obtained by oring the vector address offset to 0x0000_0000 in case of a hardware trap, by oring the vector address to 0x0000_0020 in case of a software trap. the following paragraphs detail the trap sequence for hardware and software traps. 1.3 - hardware trap sequence each hardware trap has a corresponding error code number [1]. for hardware traps, a 6-bit bus ec[5..0] conveys the error code number driven by the pmc, dmc or st120 core. if the bit psr.te (hardware trap enable) is set, a hardware trap causes the following sequence: C pcnext and the psr register are saved on the stack (p15 register, alias sp stack pointer). (see [1] exceptions handling -> types of exceptions for more details on pc next): pcnext -> [sp - 1] psr -> [sp - ? 2] figure 1 : stack overview before and after a trap sequence sp sp 0 31 stack pointer before the trap sequence stack pointer after the trap sequence direction of growth low address high address 0 31 pc next psr AN1480 - application note 4/12 C the core switches to the following state : supervisor mode : psr.pm <- 0b0 hardware loops disabled : psr.le <- 0b0 gp32 mode : psr.im <- 0b00 C the core jumps to the following address : pc <- 0x0000_0000 + (ec << 2) notes: 1. if concurrent hardware traps occur simultaneously, the one having the highest error code is taken. 2. if hardware traps are disabled (psr.te cleared) and a trap condition occurs, the st120 core performs the following : C core or a pmc trap condition : the concerned instruction is executed as a "nop" instruction and the program continues normally. C dmc trap condition caused by a store operation : the data write operation is not executed and the program continues normally. C dmc trap condition caused by a load operation : the data read operation is executed (with a potential false value) and the program continues normally. 3. all cores and pmc traps are taken independently of the guard status of the instruction. 1.4 - software trap sequence in gp32 mode, a software trap is executed as soon as "gx? trap imu4" instruction (imu4 represents an immediate value of 4 bits) with "gx" guard true is executed. in gp16 mode, a software trap is executed as soon as "trap imu4" is executed. when a software trap is executed, the st120 performs the following actions : C pcnext and the psr register are saved on the stack (p15 register, alias sp). (see [1] exceptions handling -> types of exceptions for more details on pc next): pcnext -> [sp - 1] psr -> [sp - ? 2] C the core switches to the following state : supervisor mode : psr.pm <- 0b0 hardware loops disabled : psr.le <- 0b0 gp32 mode : psr.im <- 0b00 C the core jumps to the following address : pc <- 0x0000_0020 + (imu4 << 2) this sequence is the same as the one for hardware traps except that the vector address computation is not the same. the base address to compute the vector address of a hardware trap is the reset address : 0x0000_0000 whereas the base address to compute the vector address of a software trap is : 0x0000_0020. AN1480 - application note 5/12 1.5 - trap vector address 64 traps are available. the purpose of the following table is to show the vector address of each trap. the trap description is detailed in [1] exceptions handlings -> hardware traps. notes: 1. hardware traps can be globally enabled or disabled by clearing or setting the bit te (bit 5) of the psr (processor status register). note that this bit has no effect on software traps. this bit can be set or cleared by the software instruction bfpsr0 mask value. to enable hardware traps, write : bfpsr0 0x10, 0x10 . to disable hardware traps, write : bfpsr0 0x10, 0x0 . since this instruction modifies the byte 0 in psr, the core must be in supervisor mode to execute those instructions. after a reset operation, the core is in supervisor mode and hardware traps are disabled (see [1] exception handling -> reset) 2. the st120 core allows the system to select whether data memory errors will generate traps or not. by default, the st120 core does not generate traps for data memory errors. the dmc imprecise traps are detected by the diagnostic hardware (on chip emulator) that becomes responsible to inform the host of data memory errors. table 1 : trap vector address trap type error code imu4 value trap description vector address 8 core traps 0x 0 not applicable illegal (reserved for reset) 0x0000_0000 0x 1 to 0x 4 not applicable reserved 0x0000_0004 -> 0x0000_0010 0x 5 not applicable trap.misalign 0x0000_0014 0x 6 not applicable trap.protect 0x0000_0018 0x 7 not applicable trap.opcode 0x0000_001c 16 software traps n.a imu4 = [0 ..15] trap imu4 0x0000_0020 -> 0x0000_005c 8 pmc traps 0x 18 -> 0x 1d not applicable reserved 0x0000_0060 -> 0x0000_0074 0x 1e not applicable reserved 0x0000_0078 0x 1f not applicable trap.poutofmem 0x0000_007c 8 dmc traps 0x 20 not applicable trap.dovermem 0x0000_0080 0x 21 not applicable trap.dsyserr 0x0000_0084 0x 22 not applicable trap.dsysmisalign 0x0000_0088 0x 23 not applicable reserved 0x0000_008c 0x 24 not applicable trap.dmisalign 0x0000_0090 0x 25 not applicable trap.doutofmem 0x0000_0094 0x 26 not applicable trap.dvolatile 0x0000_0098 0x 27 not applicable reserved 0x0000_009c 24 hardware traps 0x 28 -> 0x 3f not applicable undefined 0x0000_00a0 -> 0x0000_00fc AN1480 - application note 6/12 2 - software implementation for trap handlers 2.1 - the trap vector table the trap vector table is the code placed in the program memory space reserved for trap vectors. as explained in the previous paragraphs, this program memory space ranges from 0x0000_0000 to 0x0000_00fc. therefore, the first 256 bytes of the memory space are reserved. once pc has branched in the trap vector table, it then branches to a specific trap handler that is responsible for providing the user all the information to debug his code. therefore, in the trap vector table, we find 64 instructions goto associated_trap_handler. trap handler can be user-defined for each trap. the code of the trap vector table is provided in a file called AN1480 - application note 7/12 this second part of code is an extract of a typical linker file where we see the memory placement of the .startup section. # default link script for the st100 core implementation # memory mapping memory { program : org = 0x000000, len = 128k xspace : org = 0x100000, len = 16k yspace : org = 0x200000, len = 16k intios : org = 0x300000, len = 1m extios : org = 0x400000, len = 1m extern : org = 0x500000, len = 11m } # objects placement sections { .startup 0x0 : > program .picbase 0x100 : > program .thandlers : > program note: 1. it is strongly recommended to use the provided names for each trap handler (_hwtrap1, ...._swtrap0,...). otherwise, you will have to modify the file tvtable.s, build the new crt0.o before being able to link your application. the default file crt0.o is provided in AN1480 - application note 8/12 hereafter is provided the code of the thandlers.s file. .section ".thandlers", .text .define syscall_exit 2 .macro handler label .weak label .export label label: .endm .macro stop_handler barrier bkp .endm // this handler can be used if one wants to ignore // some traps .macro do_nothing_handler rte .endm .entry32 handler _hwtrap1 handler _hwtrap2 handler _hwtrap3 ...... handler _hwtrap2f stop_handler notes: 1. the file thandlers.s is placed in the program section .thanders. 2. the default trap handler routine is the same for each trap. it prevents the code from keeping running. it does not provide any information concerning the identification of the trap (hardware, software, error code) and the pc address at which one the trap occurs. AN1480 - application note 9/12 3 - how to get detailed trap handlers the following part presents a way to: C identify which trap has occurred (software, hardware, error code) C know at which pc address the trap has occurred. 3.1 - data related to a trap the information related to a trap can be stored in a c structure : enum trap {soft,hard,undefined}; typedef struct { unsigned int address; int number; /*type=1 for hardware trap, type=0 for software trap*/ enum trap type; } trap_st; do not forget to initialize the structure. trap_st trap_st = {0,-1,undefined}; 3.2 - the trap handler routines to have detailed information about a trap using the previously presented structure, the trap handler has to : C initialize as required the c structure trap_st so that when a trap occurs, the user is able to identify it by reading the content of the structure trap_st. each trap handler can be defined though the use of an assembly macro. we have called it trap_handler. its parameters are the label of the trap handler (defined in tvtable.s), its associated error code and the nature of the trap (software, hardware). hereafter is an extract of the file where one will define each trap handler : .section ".thandlers", .text .macro trap_handler label, nb, type .weak label .export label label: push p10-p11,r0-r1 makeba p10,trap_st // initialization of the structure trap_st make r0,nb sdw @(p10+4),r0 ldw r1,@(sp+28) sub r1,r1,4 sdw @(p10+0),r1 make r1,type sdw @(p10+8),r1 loopena call trap_print poprte p10-p11,r0-r1 .endm .entry32 /* definition of the core hardware traps */ trap_handler _hwtrap1,1,1 trap_handler _hwtrap2,2,1 ..... trap_handler _hwtrap2f,64,1 /* definition of the default trap_print function */ AN1480 - application note 10/12 .text .entry32 .globl trap_print .weak trap_print trap_print : barrier bkp rts notes: 1. a call to a users function is made at the end of each macro to allow a customization of each trap handler. in the given code, this function has been called trap_print. a default definition is also given which just prevents the code from keeping running. this function has been defined with a weak label so that the user may define it again with his own code. 2. inside the macro trap_handler, all the traps handlers are defined as weak labels so that the user may define again his own trap handler. 3. trap handlers can be defined at c level. here is an example for the software trap 0: __interrupt _swtrap0(void) { printf("a software trap 0 has occured\n"); } 3.3 - a way to use the function trap_print to allow a customization of the trap routines, a call to a function called trap_print is made inside each trap handler after the initialization of the c structure. by default, this trap_print function just performs a bkp instruction that prevents the code from keeping running. when stopped in the trap_print function, the user can have a look at the trap_st structure to identify the trap. one may want to print in the io window of the host the value of each data in the structure. as the function trap_print has been defined with a weak label, we can define it again. hereafter is an example of a new definition of the function trap_print at c level : #ifdef trap_print void trap_print(void) { int address; int number; int type; address= trap_st.address; number=trap_st.number; type=trap_st.type; #ifndef trap_print_map if (type == 0) printf("a software trap of number %d occurs at address 0x%8x\n",number,address); if (type == 1) printf("a hardware trap of number %d occurs at address 0x%8x\n",number,address); #else /* a printf can be specified for user/specific messages according the value of the trap number */ if (type ==0) { printf("software trap number %d at address 0x%8x\n",number,address); } if (type ==1) AN1480 - application note 11/12 { if (number < 5) printf("hardware trap reserved from core at address 0x%8x\n",address); if (number == 5) printf("hardware trap misalign from core at address 0x%8x\n",address); if (number ==6) printf("hardware trap protect from core at address 0x%8x\n",address); if (number ==7) printf("hardware trap opcode from core at address 0x%8x\n",address); if ((number >=24)&&(number <30)) printf("hardware trap reserved from pmc at address 0x%8x\n",address); if (number == 30) printf("hardware trap excecute from pmc at address 0x%8x\n",address); if (number == 31) printf("hardware trap out of memory from pmc at address 0x%8x\n",address); if (number >=40) printf("hardware trap undefined, error code = %d at address 0x%8x\n",number,address); } #endif } #endif by defining the macro-constant trap_print , the data related to the current trap are displayed in the io window. by defining the macro-constants trap_print and trap_print_map , the data related to the current trap plus its meaning (if defined) according to the trap mapping are displayed in the io window. hereafter (see figure 2) is an example of the display of the content of the structure trap_st (see browse -> globals ->trap_st) after a software trap 9. it also shows the result of the trap_print function in the io window. figure 2 : display of the content of the structure trap_st AN1480 - application note information furnished is believed to be accurate and reliable. however, stmicroelectronics assumes no responsibility for the consequences of use of such information nor for any infringement of patents or other rights of third parties which may result f rom its use. no license is granted by implication or otherwise under any patent or patent rights of stmicroelectronics. specificati ons mentioned in this publication are subject to change without notice. this publication supersedes and replaces all information previously supplied. stmicroelectronics products are not authorized for use as critical components in life support devices or systems without express written approval of stmicroelectronics. the st logo is a registered trademark of stmicroelectronics ? 2001 stmicroelectronics - all rights reserved stmicroelectronics group of companies australia - brazil - canada - china - finland - france - germany - hong kong - india - israel - italy - japan - malaysia - malt a - morocco singapore - spain - sweden - switzerland - united kingdom - united states http://www.st.com 12/12 notes: 1. the several level of "defines" (no #define, #ifdef trap_print) allow you to control the level of intrusion (library stdio.h, ...) of the detailed trap handlers in your application. 2. the trap handlers previously presented are not re-entrant. the content of the structure trap_st is the one corresponding to the latest trap. 3. about imprecise traps : only precise traps can be traced with this software. remember that only core and pmc traps are precise. imprecise traps driven by the dmc are generated some time after the error has occurred thus the architectural state of the machine will be undefined when entering in the trap handler. to work-around this, the st120 provides a diagnostic hardware that contains the necessary mechanisms for precisely locating data memory access errors. those information are sent to the host so the user has at his disposal all the required data to debug his code. hereafter is an example of information (see figure 3) returned by the diagnostic hardware (on chip emulator) to the host (ghs debugger): references [1] st120 dsp-mcu core reference guide release 1.3 - stmicroelectronics [2] embedded st100 development guide v2.0 - green hills - multi 2000 release [3] st120 dsp-mcu instruction set reference guide release 1.1 - stmicroelectronics figure 3 : example of message returned by the one chip emulator |
Price & Availability of AN1480 |
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
[Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |