Diagnosing Software Faults in Stellaris
Contents
1. OxOO000166 6026 JTE Re F4 a OxOO000164 487E LDR RO C CON1S OxOOO00L8C F44F71e0 MOY Wy Rl 256 OxOUO000L90 6008 STER E1 OxOUO00L9s 4646 Moy Ro Ra OxO0000194 pazl LDR Rl F4 OxO0000196 AOS ADD RO PC 0x16C OxO0000198 9000 STR RO SP OxO0000194 42901 CHP Rl 0x1 This disassembly screen capture shows that the processor was trying to execute a store STR instruction It was writing the value of R1 to the location of RO The exception stack frame shows the value of RO was 0x0000 0100 which is the same as the value in the MMADR The processor was trying to write a value to Flash memory which has been protected by the MPU 3 5 1 Summary 1 Foramemory management fault examine the fault status register 2 Ifthe DACCVIOL data access violation or L ACCVIOL instruction access violation bit is set the fault is due to the program violation of an MPU region access restriction If the MMARVALID bit is set then read the MMADR to determine the faulting address Examine the stack pointer to determine the location of the exception stack frame Examine the exception stack frame to find the value of the saved PC Disassemble the program at the location of the saved PC to find the instruction that caused the fault Oo a 4 Typical Faults and How to Avoid Them This section covers the most common causes of faults as determined by support requests to the Stellaris applications team ANO1286 May 2012 Diagno2. Oxd0000000 A NWIC_DEBUG STAT Ox0000004 A NVIC_MM_ ADDR 0x00000100 A NYIC_LFAULT_ADDR Oxo000olon A NVIC_MPL_TYPE oxoooooeon BARRE The value in the NVIC_FAULT_STAT register is 0x0000 0082 which means that the MMARVALID and DACCVIOL memory management status bits are set These bits indicate that a data access violation occurred and the faulting address can be found in the Memory Management Fault Address Register MMADR The screen capture above also shows a value in the MMADR of 0x0000 0100 which is in Flash memory Diagnosing Software Faults in Stellaris Microcontrollers AN01286 May 2012 Copyright 2012 Texas Instruments Incorporated la TEXAS INSTRUMENTS www ti com Typical Faults and How to Avoid Them The next step is to examine the exception stack frame The stack in this case is pointing at Ox2000 00A8 Here is a screen capture showing the exception stack frame Disassembly MPUFaultHandler Memory 1 X ox20000088 Ran we t oS Cie ari Hex 32 Bit TI Style Ox20000088 12345678 QOO00100 OO000007 0000 114 Ox2O0000088 OOO00018S QOOOORDF Geile 6 1Oo0000 Ox200000C8 OO000000 OOOO000 FFFFFFFD a4420001 OxsO00000D8 OOO010FO OOO0LODO z0000100 OCB aAggeO Ox2O00000E8 686411200 904141086 22760026 OO000E2 xz00000FS FFFFFFFD OOOOOD As before the most interesting value at this point is the saved PC which is 0x190 Disassemble the code at 0x190 Memory 1 0x188 Ale s2 o s oY
3. May 2012 Copyright 2012 Texas Instruments Incorporated 1 TEXAS INSTRUMENTS www ti com Diagnosing Faults Local 13 uwi Registers 1 X Mame se Ox 20000008 OXF FFFFFFS Ox200000C8 Ox 00000000 Ox 00000000 Ox 00000000 If your fault handler function has any code besides a simple infinity loop then it may use some stack space You must adjust the value of the stack pointer by this amount in order to find the start of the exception stack frame For StellarisWare examples the fault handler function is simple and the stack pointer points directly to the exception stack frame Use the debugger to view memory at this location Ox 200000C8 Ram F xe gh oO Gp ee a TY Hex 32 Bit TI Style Oxe200000C8 40031000 00000024 DOOOOUUes DOOOOOOO Oxe200000D8G OO0O000SE OO000S 29 Emminni OLOOUU00 Ox200000EG FFFFFFF1 44420001 OY6E3 4D0 OOOOUCK Oxe200000FG FFFFFFFI OOOOOCS In the screen capture above the first two rows show the exception stack frame The first row shows the saved values of registers RO R3 The second row begins with the saved value of R12 followed by LR PC and then xPSR register To start with the most interesting value is the PC which is Ox0000 0CBC There is a high probability that this points either directly at or near the instruction that caused the fault Use the debugger to disassemble at this address It helps to start disassembling a few instructions earlier to provide some cont
4. see Fault Status Registers for more information Exception Stack Frame The Cortex M processor uses a uniform mechanism for saving program context information on the stack This Same mechanism is used for all types of exceptions that can occur in the system including faults and interrupts When an exception occurs including a fault the following registers are pushed on the stack shown here in order of increasing address on the stack SP P00 RO SP FOA R1 SP 08 R2 SP 12 R3 SP HLO R12 SP 20 LR SP 24 PC SP 28 xPSR The register values saved in the exception stack frame provide a snapshot of the processor context at the time the exception occurred For a fault handler that is written in C the compiler saves onto the stack any additional registers that are used by the fault handling function so that the entire system context is saved in a fault handler The saved value of the working registers RO R3 R12 can be useful especially if you isolate the problem to an instruction that uses one of those registers These values allow you to reconstruct the condition of the instruction at the time the instruction executed The Program Counter PC and Link Register LR values are the most useful information that is saved in the exception stack frame First the saved value of the PC often points to the offending instruction Using the debugger to examine the instruction at that address along with the register values often provides enough clues tha
5. A NVIC_S 5_HNDOC Oxoooo0000 AY NvIC_FAULT_sTaj Ox00021000 M NWIC_HFAULT ST Ox40000000 M Mvc DEBUG STA Oxooo00009 A NVIC_LMM_ADDR OxEOQOOEDFs M NWIC_FAULT_ADD OxEQOOEDFS M mvc MPU TYPE Oxdogo00800 The NVIC_FAULT_STAT register has a value of 0x0002 1000 which indicates both a usage fault and a bus fault The usage fault status bit INVSTATE is set which means that the processor encountered a state error when it tried to execute an instruction The next step is to look at the stack pointer ANO1286 May 2012 Diagnosing Software Faults in Stellaris Microcontrollers 13 Copyright 2012 Texas Instruments Incorporated la TEXAS INSTRUMENTS Diagnosing Faults www ti com 3 4 1 3 5 14 i iil Regis Ox LFFFFFFA OX FFFFFFFS OxIFFFFFFA Ox FessoO04 Ox Fessooo4 In this case the value of the stack pointer is Ox1FFF FFF4 which is not a valid memory location The reason this memory location is not valid is because the stack was too small and overflowed Because the stack overflowed it is likely that an invalid address was used on return from a function call and the processor PC was set incorrectly causing the invalid state The other fault status bit that is set is the STKERR bus fault which means that the processor encountered an error when it tried to store the exception stack frame when the first fault occurred In this example the stack was located at the beginning of memory and when it overflowe
6. is not actually the instruction that caused the fault it must be something that happened earlier in the execution Observe that the previous instruction is another function call to the TimerLoadSet function This call is most likely where the fault occurred Use the debugger to disassemble the TimerLoadSet function and take a look near the end of this function While the imprecise bus fault does not show the exact location of the fault the value of the saved PC should be within a few instructions Therefore the fault must have occurred near the end of the TimerLoadSet function Memory 1 ES Disassembly TimerLoadset X TimerLoadset 6 an Rell Co TimerLoadSet TimerLoadSet OxOOU00D2U FOULLOFFF TST W Rl 254 OxOO000De24 DOO BEQ eCshLel OxOO000D26 bate OLR Re RO 0 26 SCSL21 FALLAFIF TST Oxooo0oDzc DOODO BEQ Oxooo0oDze AE STR RZ R0 OxOOQ000D26 Rl 65260 eleLee Ux2C Ox OO000D 30 The screen capture above shows the entire disassembly of the TimerLoadSet function Notice that the last instruction before the return is a storeimprecise STR instruction Whenever there is an imprecise bus fault it is a good idea to look for the most recent store instruction that was executed prior to the occurrence of the fault In this example this store instruction was writing to the location pointed to by RO with an offset of Ox2C By looking at the previous two disassembly screens we can see tha
7. not known When this happens it requires a little more work to find the cause of the fault than a precise error If the bus fault is due to a read instruction it produces a precise error bus fault because the processor must wait for the read cycle to complete before it can continue The invalid access occurs as the instruction executes and the exact location is known When the fault is due to a write instruction it is usually an imprecise error This is because the processor initiates the write cycle but can then continue to execute additional instructions before the actual invalid bus access write occurs Therefore the exact location is not known Summary 1 Ifa bus fault is an imprecise error find the value of the saved PC from the exception stack frame 2 Disassemble the program at the location of the saved PC It is a good idea to start disassembling a few instructions prior to the saved PC 3 Look back in the execution stream a few cycles and look for an STR instruction The most recent STR instruction that executed prior to the imprecise bus fault is most likely the cause of the fault Usage Fault Scenario plus Memory Management Fault As with the other scenarios this scenario starts with the programmer finding that the program has entered the fault handler Use the debugger to examine the NVIC_FAULT_STAT register Local 1 Hiv Registers 1 X Mame value Q myc sys PRIZ Oxdooo00000 A NVIC_S 5_PRI3 Oxo0000000
8. 000 E vic acriveo oxoovso000 Q NWIC_ACTIVE1 Oxdo000000 Q nIc PRIO x0oooo00n A MVI PRIL ox0oooo0o0 A MWIC_PRIZ Ce oooo0ooo0 In the above screen capture the debugger provides a view to see the value of this register If your debugger does not provide such a view you can examine these registers using a memory viewer starting at address OxE000 E300 In this case bit 19 of the first Active Interrupt register is set indicating that interrupt number 19 is active and is likely the cause of the interrupt If more than one bit is set in this register then the highest priority interrupt is the active interrupt Refer again to the Interrupt table in the Exception Model section of a Stellaris data sheet and look up interrupt number 19 As before this shows that the active interrupt is TimerOA Summary 1 If your program ends up in the IntDefaultHandler itis probably because the handler function was not entered in the vector table see startup code source file 2 Use the debugger to examine the lower 8 bits of the xPSR register while the program is halted in the IntDefaultHandler function and obtain the interrupt vector number 3 Look up the vector number in the Stellaris data sheet to find out which peripheral caused the interrupt 4 optional Examine the NVIC Active Interrupt registers to determine the highest priority active interrupt and look that up in the Stellaris data sheet Bus Fault Scenario 1
9. I TEXAS Application Report INSTRUMENTS AN01286 May 2012 Diagnosing Software Faults in Stellaris Microcontrollers Joe Kroesche Stellaris Software ABSTRACT During typical development efforts system operation can sometimes end up in a fault handler At first glance faults might seem cryptic or difficult to understand but Stellaris microcontrollers include several features to help determine why a fault occurred Read this application note to learn about the fault handling capabilities of Stellaris microcontrollers how to diagnose faults and how to prevent them Contents 1 EME OCG OMA R siren oye picasa E ci E E E E E E E EE E S A E T EE 1 2 Fault System Overview nnnnnnnnnrrrrrrrrrrrrrrrrrrrrrrrnrnnrnnnnnnnnnnnnnnnnnnrnrrrrrrrnnnrnrerannrerrrrrrrrrrrrrrrrrrrrrree 1 3 DONO I HAWS ea E EE EEE EE r E E E EE ERER 4 4 Typical Faults and How to Avoid Them snnunnsnnnnnssernnrrrrrrrrenssrrsrrrrrrrrrrrrrrsrrrrrrrrrrrrrrrrrrrrrtrrrrrrrrrree 15 5 General Faut Debug FIOW riseterisi i ensis Erenus EE S EEE E EEEE EAER ANE A Ta 18 6 COM CHUS ION a s2aaciedavececcestanccnetatanecesavececcsaceneehcesenceasiecantsnsaceueetebean ue cteesqacees senaeie aecenaees aadeatarseeunees sees 18 T FR UI aos E whic ae E we ic ce E E seed E E E 18 1 Introduction When software running on a Stellaris Cortex M processor encounters an error it generates a fault and the program execution is directed to a fault handler In some cases fault occurre
10. In this common scenario when using a debugger the programmer finds that the program has entered the Hard Fault handler ee ee a ee ce i z static void FaultISkivoidi IO 0 H ff ff Enter an infinite loop ff while i i n mlm mc om amp sli Bee e PePe Woo wo lwo m Ie Ww w He eS e In io o 6 Diagnosing Software Faults in Stellaris Microcontrollers AN01286 May 2012 Copyright 2012 Texas Instruments Incorporated la TEXAS INSTRUMENTS www ti com Diagnosing Faults In this example use the debugger to examine the fault status register Your debugger may provide a viewer for this register as shown below or you can use a memory viewer to examine address OxE000 ED28 Local 1 Hii Registers 1 X A NvIc_s s_PRIZ Oxcoooo0o0o0 A NvIC_s S_ PRIS Oxcoooooo0 A NvIc_s S_HND CTRL Oxooooo000 MVIC FAULT STAT Ox00008z200 aa A NVIC_HFAULT STAT Ox4oooo0000 D NvIC_DEBUG STAT Ox00000008 A NVIC_MM_ADDR Ox4003100C D NvIC_FAULT_ADDR Ox4003100C p MYIC_MFPO_TYPE OxOOOO0800 p WIC MPU CTRL OxOOOO00000 A MIC MPU NUMBER Oxooo0o0o000 fl PA nwt Mp RSF henna In this case the NVIC Fault Status NVIC_FAULT_STAT register has a value Of 0x0000 8200 Refer to any one of the documents listed in the References section or to Diagnosing Faults to see the meaning of the bits in this register The value shown here indicates a bus fault and the bits tha
11. ated I TEXAS INSTRUMENTS General Fault Debug Flow www ti com 5 General Fault Debug Flow Listed below are the general steps to follow to debug a fault These are the steps used in the examples earlier in this application note Often you can collect enough clues to allow you to solve the problem before it becomes necessary to follow all the steps 1 Examine the NVIC_FAULT_STAT register at OxEO00 ED28 to determine the type of fault 2 If either the MMARVALID or BFARVALID bits are set read the corresponding Fault Address Register MMADR or FAULTADDR to get the faulting address 3 Find the value of the stack pointer in the fault handler 4 fneeded adjust the stack pointer to find the address of the exception stack frame This step is necessary if your fault handler function allocates storage on the stack For the StellarisWare examples no adjustment is needed 5 Get the value of the saved PC from the exception stack frame 6 Disassemble the code at the location of the saved PC to find the instruction that caused the fault Sometimes the saved PC does not point to the exact instruction that caused the fault but only in the general location 7 Foranimprecise bus fault look for the most recent store instruction that executed prior to the occurrence of the fault 8 Use the saved values of the other working registers as needed to reconstruct the instruction operands 9 Use the saved value of the LR to find the prior function in t
12. d it went outside the bounds of SRAM making it is easy to spot the problem However depending on the tool chain used and other factors the stack may not be located at the beginning of memory If it is not at the beginning of memory and it overflows then it may overwrite some data and code that changes that data could also corrupt the stack This problem is more subtle but can be the source of usage faults because the processor may return from a function to an invalid address for the PC Summary 1 Ifa usage fault occurs examine the NVIC_FAULT_STAT register to find the type of usage fault 2 Examine the stack pointer to find the exception stack frame 3 Ifthe stack overflows or is corrupted the exception stack frame may not be available 4 For INVPC invalid PC INVSTATE invalid state or UNDEFINSTR undefined instruction usage the most probable cause is stack overflow or stack corruption Memory Management Fault Scenario This scenario makes use of the StellarisWare mpu_fault example which uses the MPU The MPU can be used to set up protected memory regions and when the processor executes code that violates a protected memory region a memory management fault occurs Here is a screen capture showing the NVIC_FAULT_STAT register after the program enters the fault handler Local 1 Watch Monaste aa D mee 4 Marne Value A NVIC_5 5_PRI3 oxoooooood A NYIC_SYS_HNDUCTRL Ox000l000l E vIC_FAULT_STAT A NYIC_LHFAULT STAT
13. d LR may not always provide a useful backtrace but it can often be used this way to go back a level in the program Summary If your program ends up in the hard fault handler Fault ISR there are two methods to use to find the cause and sometimes both are needed Method 1 1 Use the debugger to examine the NVIC_FAULT_STAT register to find the type of fault and the status bits that indicate the specific cause 2 If there is a valid fault address register FAULTADDR or MMADR then read that to find the faulting address 3 Study the memory map in the Stellaris data sheet to find a clue about the cause of the fault Often the address is in the register space of a peripheral 4 Use this information to go back to the source code and try to identify the section of code that is causing the problem Method 2 1 Use the debugger to find the value of the stack pointer 2 Adjust the value of the stack pointer if your fault handler uses the stack otherwise use the value as it is 3 Use the debugger to examine eight words of the exception stack frame that are pointed to by the value of the stack pointer SP Diagnosing Software Faults in Stellaris Microcontrollers AN01286 May 2012 Copyright 2012 Texas Instruments Incorporated la TEXAS INSTRUMENTS www ti com Diagnosing Faults 4 Find the saved value of the PC and disassemble code at that address to try to find an instruction that may have caused the fault Use the va
14. e allocated for mystring which overwrites any other stack variables saved registers and return address and possibly the stack context of the function that called this function A similar thing can happen if a numerical array is allocated on the stack and is then written from a for loop Perhaps the index limits of the for loop match the array size when the programmer first created the function but then later the for loop index limit is increased without also increasing the size of the allocated array Here is another problem that happens more often than you think Diagnosing Software Faults in Stellaris Microcontrollers AN01286 May 2012 Copyright 2012 Texas Instruments Incorporated I TEXAS INSTRUMENTS www ti com Typical Faults and How to Avoid Them 4 4 VOLG MyEune vold int myarray 1024 In this case the programmer allocated a huge array on the stack Unless the stack was adjusted for an unusually large program this will likely cause a stack overflow the first time this function is entered Note Be careful with arrays allocated on the stack and with array bounds in general Bad PC Address There are a couple of common pitfalls that can cause a bad PC address Both usually occur when using a function pointer to call another function In the first example the function pointer is called before it has been initialized void myfunc void vord Amyptn Goud mypEn s The compiler g
15. ed Bus fault A bus fault occurs when there is an Configurable lower than Hard fault Optional Escalates toa error on the bus that happens when Hard fault accessing a peripheral or memory Usage fault A usage fault occurs when there is a Configurable lower than Hard fault Optional Escalates to a program error such as an illegal Hard fault instruction alignment problem or attempt to access a non existent CO processor a Only the reset and non maskable interrupt NMI exceptions are higher in priority than the hard fault The Hard fault has the highest priority of any fault in the system The priority of the fault is fixed at 1 and the only higher priority exceptions in the system are reset and non maskable interrupt NMI The remaining fault types have configurable priority levels but are typically lower priority than the Hard fault and higher priority than every other type of exception or interrupt Only the Hard fault is required and cannot be disabled The other three fault types can be enabled or disabled in the system If one of the other three fault types occurs and is not enabled then it is escalated to a Hard fault See the documentation from the References section for more details about fault types and how they can be configured When a fault occurs there are two useful tools available to find the cause the exception stack frame see Exception Stack Frame for more information and the fault status registers
16. ed information or support that may be provided by TI Further Buyers must fully indemnify TI and its representatives against any damages arising out of the use of TI products in such safety critical applications Tl products are neither designed nor intended for use in military aerospace applications or environments unless the TI products are specifically designated by TI as military grade or enhanced plastic Only products designated by TI as military grade meet military specifications Buyers acknowledge and agree that any such use of TI products which TI has not designated as military grade is solely at the Buyer s risk and that they are solely responsible for compliance with all legal and regulatory requirements in connection with such use TI products are neither designed nor intended for use in automotive applications or environments unless the specific TI products are designated by TI as compliant with ISO TS 16949 requirements Buyers acknowledge and agree that if they use any non designated products in automotive applications TI will not be responsible for any failure to meet such requirements Following are URLs where you can obtain information on other Texas Instruments products and application solutions Products Applications Audio www ti com audio Automotive and Transportation www ti com automotive Amplifiers amplifier ti com Communications and Telecom www ti com communications Data Converters dataconverter ti com Computers and Periph
17. enerates code to call the function through the function pointer and if this pointer does not point to a function the PC can end up anywhere This error can cause any of the following e The processor jumps to valid code somewhere in the program and continues executing The bug does not show up until later e The processor jumps to some location in memory that does not contain a valid instruction and a usage fault probably occurs e The processor jumps to a location outside the valid memory window and a bus fault and or usage faults occur Another problem can happen when using a hard coded address for the function pointer mypfn 0x100 hard coded address of jump destination mypfin This error causes an INVSTATE usage fault which occurs because even though instructions are 16 bit aligned always even address the ARM based processor core uses the lower bit of the destination address to determine the instruction mode ARM or Thumb The Cortex M processor always executes in Thumb mode so the target address always has the lower bit set If you disassemble code produced by the compiler notice that the address it uses for functions is always odd Also if you look back in this application note at some of the screen captures showing the exception stack frame note that the saved value of the LR is also always odd ANO1286 May 2012 Diagnosing Software Faults in Stellaris Microcontrollers 17 Copyright 2012 Texas Instruments Incorpor
18. erals www ti com computers DLP Products www dip com Consumer Electronics www ti com consumer apps DSP dsp ti com Energy and Lighting www ti com energy Clocks and Timers www ti com clocks Industrial www ti com industrial Interface interface ti com Medical www ti com medical Logic logic ti com Security www ti com security Power Mgmt power ti com Space Avionics and Defense www ti com space avionics defense Microcontrollers microcontroller ti com Video and Imaging www ti com video RFID www ti rfid com OMAP Mobile Processors www ti com omap Wireless Connectivity www ti com wirelessconnectivity TI E2E Community Home Page e2e ti com Mailing Address Texas Instruments Post Office Box 655303 Dallas Texas 75265 Copyright 2012 Texas Instruments Incorporated
19. ext for the disassembled code Memory 1 Ease embly Timercontigures J Oxcbo B SEs C5 VERE OAL UALS 3 TimerConfigure OxOOO00CBC DoC 7 a RO 0xC OxOOOOOCBE 4405 LDR Re CsCOns OxOOO00CCO 4014 AND Rea K3 OxOOO00CCE b0Ce LR Ra RO 0x C Ox OO0000CC4 DEDA Lok Re Rl 0x16 OxOO000CCE6 6002 LR Ra RO OxOOO00CCE BACA UXTE Re Rl mn Oononee Ana STR R TAN 0wAdl The instruction at 0x0000 0CBC is most likely the one that caused the fault It is an LDR instruction and is reading from the address in RO plus an offset of OxC Refer back to the previous screen capture to see that the saved value of RO was 0x4003 1000 and adding OxC gives 0x4003 100C The processor was trying to read from 0x4003 100C and this is likely what caused the fault You can see that this is the same conclusion ANO1286 May 2012 Diagnosing Software Faults in Stellaris Microcontrollers 9 Copyright 2012 Texas Instruments Incorporated la TEXAS INSTRUMENTS Diagnosing Faults www ti com 3 2 1 10 that was found earlier in this section by examining the fault status register and the FAULTADDR register So we have used a second method to find the same cause for the fault Because the cause of this fault has been found by two different methods no further debugging is necessary Even though this problem has been debugged for the purpose of demonstration we can also used the saved value of LR to find a little more inf
20. he call stack Sometimes the saved LR value cannot be used this way 6 Conclusion The Stellaris Cortex M processor provides a powerful fault handling system and several features to help you find the cause of a fault After debugging a few faults you will be more comfortable handling and troubleshooting faults as they happen and will be able to find the cause in a few minutes 7 References This application note provides information about Stellaris Cortex M registers and other features related to fault handling This information is presented at a summary level and does not serve as a reference for these features For detailed information about Stellaris fault handling see the following related documents which are available on the Stellaris web site at www ti com stellaris e Stellaris Microcontroller Data Sheet e Sfellaris Errata e ARM Cortex M Errata e Cortex M3 M4 Instruction Set Technical User s Manual e The Definitive Guide to the ARM Cortex M3 by Joseph Yiu 18 Diagnosing Software Faults in Stellaris Microcontrollers AN01286 May 2012 Copyright 2012 Texas Instruments Incorporated IMPORTANT NOTICE Texas Instruments Incorporated and its subsidiaries Tl reserve the right to make corrections modifications enhancements improvements and other changes to its products and services at any time and to discontinue any product or service without notice Customers should obtain the latest relevant information before placi
21. lues of the saved registers to reconstruct the instruction parameters 5 If further context is required disassemble code pointed at by the saved value of the Often this reveals the previous function in the call stack and helps to identify the cause of the fault 3 3 Bus Fault Scenario 2 In this scenario like Bus Fault Scenario 1 the programmer finds that the program is entering the hard fault handler Fault ISR As before use the debugger to examine the NVIC_FAULT_STAT register Local 1 uwi Registers 1 X Mame Value A NVIC_S 5_PRI3 oxoooooood A NWIC_S S HNDOCTRL Ox00000000 i NVIC FAULT STAT Ox oo000400 J A NVICLHFAULT STAT Ox40000000 A NYIC_DEBLUIG STAT Ox 00000008 Jalala aa mA Q NWIC_MM_ADDR OxEQOOEDFS D NVIC_FAULT_ADDR OxEQOOEDFS A NVIC_MPLLT PE Oxoooo0so0 3 NVIC_MPLCTRL oxooco0o0d Fa RITO MDE RI imMee O Aw AANA AA This time the value in the NVIC_FAULT_STAT register is 0x0000 0400 The IMPRECISERR bit is set which means that a bus fault occurred but that the exact faulting address is not known In order to try to debug this we will use the exception stack frame Find the value of the stack pointer This value may need to be adjusted if your fault handler uses the stack For StellarisWare examples the stack pointer in the fault handler does point to the exception stack frame In this example the stack pointer is Ox2000 00C8 so use the debugger to view memory at this loca
22. m Tl under the patents or other intellectual property of TI Reproduction of Tl information in Tl data books or data sheets is permissible only if reproduction is without alteration and is accompanied by all associated warranties conditions limitations and notices Reproduction of this information with alteration is an unfair and deceptive business practice TI is not responsible or liable for such altered documentation Information of third parties may be subject to additional restrictions Resale of Tl products or services with statements different from or beyond the parameters stated by TI for that product or service voids all express and any implied warranties for the associated TI product or service and is an unfair and deceptive business practice TI is not responsible or liable for any such statements Tl products are not authorized for use in safety critical applications such as life support where a failure of the TI product would reasonably be expected to cause severe personal injury or death unless officers of the parties have executed an agreement specifically governing such use Buyers represent that they have all necessary expertise in the safety and regulatory ramifications of their applications and acknowledge and agree that they are solely responsible for all legal regulatory and safety related requirements concerning their products and any use of TI products in such safety critical applications notwithstanding any applications relat
23. nce in a program can seem mysterious and difficult to debug However a fault should not be the cause of debug trepidation The Stellaris Cortex M processor provides a powerful fault handling system and several features to help you find the cause of a fault After debugging a few faults you will be more comfortable handling and troubleshooting faults as they happen and will be able to find the cause in a few minutes 2 Fault System Overview In a Stellaris Cortex M processor a fault is a type of exception There are 15 system exceptions including SysTick and SVC Four of these system exceptions are faults with one for each type of fault that can occur in the processor when it is running code Table 1 shows the list of fault types and their causes Table 1 Fault Types Hard fault A hard fault includes any fault that is Highest priority fixed at 1 Required Not applicable not covered by the following three categories Any unhandled fault escalates to a hard fault Memory A memory management fault occurs Configurable lower than Hard fault Optional Escalates toa Management fault when executing code attempts to Hard fault access an illegal location or violates a rule of the Memory Protection Unit MPU ANO1286 May 2012 Diagnosing Software Faults in Stellaris Microcontrollers 1 Copyright 2012 Texas Instruments Incorporated la TEXAS INSTRUMENTS Fault System Overview www ti com 2 1 2 Table 1 Fault Types continu
24. nction entered in the vector table Once it is known that the program has entered the default handler it is often obvious which interrupt has triggered and has no handler In this case there is no further debugging required However sometimes you want to find out which peripheral caused this interrupt to happen The quickest way to find Diagnosing Software Faults in Stellaris Microcontrollers AN01286 May 2012 Copyright 2012 Texas Instruments Incorporated la TEXAS INSTRUMENTS www ti com Diagnosing Faults ANO1286 May 2012 out is to look at the value of the Program Status Register xPSR register The lower 8 bits contain the number of the current exception Local 1 Hii Registers 1 X Mame value E A Core Registers oot PC 0x00000932 ool SP Oxz00000r8 oot LR OxFFFFFFFS tial RO Ox40031000 Moi Red Oxd0000001 hol RZ Oxoooo0000 tial R3 Ox00000101 In the above example the lower 8 bits of the xPSR register show the exception number is 0x23 or 35 decimal Referring to the Interrupts table in the Exception Model section of the Cortex M Processor chapter of a Stellaris data sheet shows that vector number 35 is Timer OA Now look in the vector table usually in the startup code at the vector for TimerOA _ a i ee ee ey 102 IntDefaultHandler f f ADT Sequence 3 oo a 103 IntDefaultHandler f Watchdog timer 104 IntDefaultHandler ff Timer O subtimer A 105 IntDefaultHandler E Timer O s
25. ng orders and should verify that such information is current and complete All products are sold subject to Tl s terms and conditions of sale supplied at the time of order acknowledgment Tl warrants performance of its hardware products to the specifications applicable at the time of sale in accordance with Tl s standard warranty Testing and other quality control techniques are used to the extent Tl deems necessary to support this warranty Except where mandated by government requirements testing of all parameters of each product is not necessarily performed Tl assumes no liability for applications assistance or customer product design Customers are responsible for their products and applications using TI components To minimize the risks associated with customer products and applications customers should provide adequate design and operating safeguards TI does not warrant or represent that any license either express or implied is granted under any TI patent right copyright mask work right or other TI intellectual property right relating to any combination machine or process in which TI products or services are used Information published by TI regarding third party products or services does not constitute a license from TI to use such products or services or a warranty or endorsement thereof Use of such information may require a license from a third party under the patents or other intellectual property of the third party or a license fro
26. ormation From a previous screen capture the saved LR value was Ox0000 05A9 Again use the debugger to disassemble code at this address Memory 1 Disassembly main Oxse gt ox5a0 lle a 2 B ri 7 15 5 TimerConfigure TIMNERO BASE TIMER CFG 32 BIT PER OxOO0005A2 4620 Hoy Ro R4 OxOO000544 NOOFBSA B Tiner Configare 156 TimerConftigure TIMER BASE TIMER_CFG_32_BIT_FER OxOO00005H6 FUFFFDA2 BL aysCtlClockGet OxOO000S5A4C ZlFF Moy Rl 0x FF OxOO0005ME 4602 Moy Re Ro OxOOO0005BQ0 4626 Moy RO KS There are several things to note about this disassembled code First the LR was 0x5A9 The lower bit of the address is set and the address is odd This is the way the ARM based processor indicates it is running in Thumb mode So the real address of the instruction is Ox5A8 The LR points to the address that executes on return which means that the instruction that made the function call is the instruction before the LR address In the screen capture above this instruction is a call to the TimerConfigure function from the main function indicating the location in the main function that made a call to the TimerConfigure function causing the bus fault So even though it was not necessary for this example to debug this far these methods demonstrate a way to obtain more information about what your program is doing when a fault occurs and helps you to trace back to the source of the problem The save
27. ruction that attempted to divide by zero This trap can be enabled or disabled a UNALIGNED Traps an attempt to make an unaligned memory access This trap can be enabled or disabled o UNDEFINSTR __ Aomptio oxeoute an ndetnedinsiucion Diagnosing Faults Here is a common debugging scenario 1 Developer discovers the application stops running 2 Using a debugger developer discovers that the application ends up in a fault handler 3 Developer gets stuck not knowing what to do and asks for support The goal of this application note is to demystify step 3 and provide the developer with techniques to use to get the application running again The remainder of this section presents different fault scenarios and shows how to use the Stellaris features described in the previous section to determine the cause of the fault Default Interrupt Handler Technically this is not a fault However this common scenario appears in customer support requests to the Stellaris applications team The following screen capture shows a program that is halted in the IntDefaultHandler function 204 27205 Paa c a a a r a a a a a r r a a r a a a a a a a r a a a a a a a a a a a a s a a a a a a a a aa oa 206 static roid 20 gt IntDbetaultHandler roid 208 if 209 if 210 f Go into an infinite loop Z11 i Gleiz while i1 2135 214 i 215 216 Once here it is safe to assume that an interrupt occurred that does not have a handler fu
28. s at OxE000 ED28 e Bus Fault Status BFAULTSTAT register 8 bits at OxEO00 ED29 e Usage Fault Status UFAULTSTAT register 16 bits at OxEO00 ED2A Each of these fault status registers contains status bits to indicate the cause of the fault Also for the memory management and bus fault types there is an address register that holds the address that caused the fault The three status registers can be read at separate addresses as shown above but typically are read as a combined 32 bit word from address OxE000 ED28 2 2 1 Memory Management Fault Status MFAULTSTAT Register Name Description MMARVALID Valid 2 address is stored in the Memory Management Address Register ee 6 5 junuseed re access violation occurred while mee on oa entry oe O o vo ronas SSS Bit 7 is set if the Memory Management Fault Address Register MMADR located at OxE000 ED34 contains the address that caused the memory management fault 2 2 2 Bus Fault Status BFAULTSTAT Register Bit Name Oesenton e o eser onse Bit 7 is set if the Bus Fault Address Register FAULTADDR located at OxE000 ED38 contains the address that caused the bus fault ANO1286 May 2012 Diagnosing Software Faults in Stellaris Microcontrollers 3 Copyright 2012 Texas Instruments Incorporated la TEXAS INSTRUMENTS Diagnosing Faults www ti com 2 2 3 Usage Fault Status UFAULTSTAT Register 3 1 4 Bit Name CBesenption DIVBYZERO Traps an inst
29. sing Software Faults in Stellaris Microcontrollers 15 Copyright 2012 Texas Instruments Incorporated la TEXAS INSTRUMENTS Typical Faults and How to Avoid Them www ti com 4 1 4 2 4 3 16 Bus Fault Due to Disabled Peripheral This type of fault is most commonly seen in customer help requests regarding faults Any attempt to access a disabled peripheral including DriverLib APIs results in a bus fault To avoid this fault be sure to call the SysCt 1PeripheralEnable function for all peripherals used by your application Various Faults Caused by Stack Overflow Stack problems are another common reason for support requests Stack problems can be manifested in obscure ways including multiple faults and problems that do not appear at the time of the original stack error but instead appear much later during program execution These problems can be tricky to debug If your application is encountering a fault or multiple faults and the cause is not obvious take a look at the stack allocation Often it is helpful just to examine the value of the stack pointer when the fault occurs and compare it to the valid range for the stack pointer from the map file If the stack pointer is near the base address of the stack then that is evidence that your stack might be too small Try increasing the stack size by 50 or 100 to see if the problem disappears A function that is using a stack that has overflowed its bounds overwrites memory o
30. t are set are BFARVALID and PRECISERR This means that the Bus Fault Address Register FAULTADDR register contains the exact value of the address that triggered the bus fault Use the debugger to view the value of the FAULTADDR register If the debugger does not have a viewer for this register you can examine the memory at address 0xE000 ED38 Local 1 vil Registers 1 X A VIC FAULT STAT Oxoocos200 3 NvIC_HFAULT_STAT oxa0000000 D NVIC_DEBLIG_STAT 0x0000000E 3 Ic MM ADDR 0x4003100C NVIC_FAULT_ADDR ox4003100c 3 NVIC_MPULTYPE Oxoocoo8c0 D NVIC_MPUL CTRL Oxoocooood p MYI MPU _MNUOMBER OxOO000000 p MvIC_MPU_BASE Ox O0000000 p Mv MPU_ATTR Ox O0000000 p MYIC_MFU_BASE1 Ox 00000000 D NVIC_MPUL ATTRA Oxoocoood The value in the NVIC Fault Address NVIC_FAULT ADDR register is 0x4003 100C Refer to the Memory Map table in the Memory Model section of the Cortex M Processor chapter of the Stellaris data sheet which shows that the faulting address is in the register space of the Timer 1 peripheral ANO1286 May 2012 Diagnosing Software Faults in Stellaris Microcontrollers 7 Copyright 2012 Texas Instruments Incorporated la TEXAS INSTRUMENTS Diagnosing Faults www ti com 0x4002 D000 0x4002 DFFF QEl1 0x4002 E000 Ox4002 FFFF Reserved 0x4003 0000 0x4003 0FFF Timer 0 0x4003 2FFF Timer 2 Ox4003 3FFF Timer 3 Ox4003 FFF Reserved 0x4003 8FFF ADCO 0x4003 2000 0x4003 3000 Ox4003 4000 0x4003 8000 This means tha
31. t no code has modified RO since this store instruction was executed and RO still holds the same value it had at that time Get the value of RO either by viewing the current processor registers or looking at the stored value in the exception stack frame screen capture above which in this case is 0x4003 1000 As in the Bus Fault Scenario 1 consult the Stellaris data sheet to see that this address is in the register space of the Timer 1 peripheral Now that we suspect that the fault was caused by a write to a Timer 1 register go back to look at the source code to try to find a call to the TimerLoadSet function 12 Diagnosing Software Faults in Stellaris Microcontrollers AN01286 May 2012 Copyright 2012 Texas Instruments Incorporated I TEXAS INSTRUMENTS www ti com Diagnosing Faults Lc timers c has c startup occs c 3 3 1 3 4 140 141 if 142 ff Enable the peripherals used by this example 145 ff 144 S SCtlPeripheralEnable syscTL PERIPH TINERO 145 146 i 147 f Load Timer 1 148 ff 149 TimerLoadSet TIMER1 BASE TIMER amp SyscCrlClockGetrt 150 Here is a Call to the TimerLoadSet function Looking back in the program we see that there was no function call or other code to enable the Timer 1 peripheral which is why the bus fault occurred This bus fault scenario is similar to the previous one except that in this case there was an imprecise bus fault and the exact faulting address was
32. t some part of the program was trying to access Timer 1 and caused a bus fault Note This is a common support scenario for the Stellaris applications team When there is a bus fault and the faulting address is in the register space of a peripheral it is almost always because the programmer did not enable the peripheral before trying to use it Consider the following code snippet The programmer enabled Timer 0 but forgot to add an additional line of code to enable Timer 1 timers c X startup occs c 140 141 if 142 fy Enable the peripherals used by this example 143 if 144 syeCtlPeripheralEnable SYsCTL PERIPH TIMERQO 145 146 i 147 fy Enable processor interrupts 146 i 149 IntMasterEnable i 150 The following shows the correct code This eliminates the fault Lc timers c ic startup _ces c 140 141 ff 142 ff Enable the peripherals used by this example 143 ff 144 ayeCtlPeripheralEnable SYSCTL PERIPH TIMERO 145 oyattlFPFeripheralEnable eet ky FERIFH TIMEEL J 146 14 ff 146 ff Enable processor interrupts 145 ff 150 IntMasterEnable li 151 At this point the cause of this fault has been found and corrected and no further debugging is required However another path could be taken to find the problem and that is to start with the exception stack frame Use the debugger to find the value of the stack pointer 8 Diagnosing Software Faults in Stellaris Microcontrollers AN01286
33. t the cause of the fault becomes apparent Sometimes it is not that easy though and the saved PC only points in the vicinity of the problem or does not provide any useful information at all this is rare Diagnosing Software Faults in Stellaris Microcontrollers AN01286 May 2012 Copyright 2012 Texas Instruments Incorporated 1 TEXAS INSTRUMENTS www ti com Fault System Overview Second the saved value of the LR can often be used to provide you with some context about what your program was doing when the fault occurred For example if the code was executing in a certain function when the fault occurred the saved LR might point back into the function that called it By examining the code at the location pointed to by the saved LR you might be able to tell more about the calling function The saved LR can also be used in conjunction with the rest of the stack to unwind a series of function calls providing an even better history However this process is a lot of trouble to do manually without an automatic stack backtrace from the debugger and is usually only necessary in tricky debug situations Sometimes the exception stack frame is not available This usually happens when the stack pointer is pointing to a non RAM location which might be due to stack corruption or overflow 2 2 Fault Status Registers There are three fault status registers one for each type of fault e Memory Management Fault Status MFAULTSTAT register 8 bit
34. tion i Ae es Disassembly Faultl Sr ox200000c8 Ran ee SS a ot oO Hex 32 Bit TI Style Ox200000C8 40031000 OOO000FF O0sD0900 00741200 Ox200000D8 OOOO00SE OO0004D5 mmnm 41000000 Ox2Z00000RG FFFFFFF1 44420001 40030000 OOO00CCS Oxe200000FSG FFFFFFF1 OOOOOC4SS The first two rows in the screen capture above show the exception stack frame The first row shows the saved values of registers RO R3 The second row shows the saved value of R12 LR PC and xPSR Use the debugger to disassemble code at the location of the saved PC 0x4D4 ANO1286 May 2012 Diagnosing Software Faults in Stellaris Microcontrollers 11 Copyright 2012 Texas Instruments Incorporated 13 TEXAS INSTRUMENTS www ti com Diagnosing Faults Memory t1 Disassembly main Oxsc a Ox4D0 Jlle lle ri 149 TimerLoadSet TIMER BASE TIMER 4 SysCtlCloi a OxUOOOU04DO FOUOFCZ6 BL TinerLoadset 154 IntiWasterEnable OxOOO004D4 FOOOFCSD BL IntM asterEnable 159 Tiner Configure TIMERO BASE TIMER CFG 32 BIT OxOOOOU04DS wee LDR Rs 8CsCONs OxOOO004DA elec Hoy Rl 0xea2 OxOOOO004DC 4626 Mov RO RS Ox QO0004DE FOOUFBFS BL Timerlonftigqure 160 TimerContiqure TIMER BASE TIMER_CFG 32 BIT OxOOO004E 2lee Mow Rl 0x22 OxOOO004E 4 4620 Moy Ro R4 The instruction that is pointed to by the saved PC is a function call to IntMasterEnable However because this is an imprecise bus fault we know that this
35. ubtimer E 106 TimeriliIntHandler ff Timer 1 subtimer A 107 IntDefaultHandler ff Timer 1 subtimer B 108 IntDefaultHandler ff Timer 2 subtimer i 109 IntDefaultHandler f f Timer 2 subtimer B 110 Tnt Defanlt Handler ff inalaa Cornaratnr M The above screen capture shows that the vector entry for Timer OA is the IntDefaultHandler function which is the default when no handler has been provided In this case the correct handler function was not entered in the table The screen capture below shows the correct handler function entered in the vector table r r bki P e j e a l im 102 IntDefaultHandler ff ADC Sequence 3 103 IntbefaultHandler ff Watchdog timer 104 TimerOIntHandler ff Timer O subtimer A 105 IntDefaultHandler ff Timer O subtimer BE 106 TimeriiIntHandler ff Timer 1 subtimer A 107 IntbefaultHandler ff Timer 1 subtimer E 1068 IntDefaultHandler ff Timer 2 subtimer A 109 IntDefaultHandler E Timer 2 subtimer B Diagnosing Software Faults in Stellaris Microcontrollers 5 Copyright 2012 Texas Instruments Incorporated la TEXAS INSTRUMENTS Diagnosing Faults www ti com 3 2 Another way to determine which interrupt caused the processor to enter the default handler is to examine the NVIC Active Interrupt registers to see what interrupt is active as shown below Local 1 nid Registers 1 X Name value Q MIC PENCO x0ozoo000 A MIC PENDI oxoo00oo00 3 WWIC_UNPENDO Oxoozooo00 Q NWICLUNPEND1 oxdo000
36. utside the space allocated for the stack Often this is storage for program variables If this happens the values of those variables become corrupted and the program will not run correctly This may not create a fault until later Another issue that can occur when a function is running with an overflowed stack is that the function itself may use a variable that is in the space that has been overwritten by the stack The function may write a value to that variable destroying the value that was saved on the stack and then either saved registers or even the PC might have the wrong value when the function returns This error can cause strange behavior including returning to a wrong address Stack Corruption Due to Buffer Overflow Sometimes a function uses an array that is allocated on the stack and then in the function body the array is written beyond its bounds This error can have the effect of overwriting other automatic variables used in the function as well as overwriting saved registers and the return address One example is a function that looks like this void myfunc void char mysteing 3 lz usprintf mystring my formatted output S d n somevar In the above example eight bytes were allocated on the stack for the character array Later the usprintf function was used to store text characters in the array without considering the array bounds The format string and the numerical value are written beyond the end of the spac
Download Pdf Manuals
Related Search