Good question! I'll make sure a section is added to the
Debugging section of the documentation for the next release. For now, all the information you should need is here:
The strategy that you used was very successful as you managed to identify the source code line with the problem - that is usually 90% of the task. The remaining 10% is diagnosing exactly what is wrong.
In my experience hardware faults are usually related to bad addresses so to work out what was wrong I needed to find out what was wrong with the address.
These were the steps I followed to do that:
- Compile TestSinglePWM.mod
- Select Project > Disassemble to look at the disassembly listing for the problem source code line that you identified:
Code: Select all
SYSTEM.GET(MCU.PWM1TCR,s);
. 176 F8DFB000H ldr r11,[pc+offset] <Const:6>
<Const:6> is defined a little further down:
- Checked address PWM1TCR in the NXP LPC17xx User manual (UM10360) and saw that it should be 0x4001 8004 (40018004H)
- Looked for the definition of PWM1TCR in LPC1769\MCU.mod and found the error.
Traps caused by runtime errors or assertion failures are easy to locate as they give you the module name and line number of the offending line of source code. Hardware and other system traps like the one that you identified are more difficult to locate as they can only give you the address of the instruction that failed. Fortunately they are much more rare than runtime errors.
The next time you encounter a problem like this, the quickest way to identify the line of code is to use the disassembler listing in association with the map file. The map file is produced when you link the application.
For your example, if you use a text editor to look at the contents of the file TestSinglePWM.map you wil see that the code of that module starts at address 000001DDCH. The error message reported the hardware fault at address 00001E90H.
The disassembler listing shows relative addresses rather than absolute addresses. If you subtract 000001DDCH from 00001E90H that will give you the offset of the instruction within that module = 180. The Cortex-M3 program counter is 4 bytes ahead of the current instruction so that means that the actual offset of the offending instruction is 180 - 4 = 176.
If you look at the disassembler listing you will see the instruction with offset 176 preceded by the source code line which generated it:
Code: Select all
SYSTEM.GET(MCU.PWM1TCR,s);
. 176 F8DFB000H ldr r11,[pc+offset] <Const:6>
Eureka!