debugging in the case of hardware faults

[abaumann]

Hi,

this Topic is relate to the topic [viewtopic.php?f=3&t=416]"problems with PWM[/url]".

I create this additional topic to address the question what can we do if hardware faults occurs.

Are there debugging strategies related to oberon and Cortex M3 based boards ?

The only information I get is the address.

Does exist MCU related error codes related to hardware faults ?

Best regards


Andreas

[cfbsoftware]

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:

  Code: Select all

  .   208 <Const:6>   4001804H
  

• 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!

[abaumann]

Hi,

Thank you for your explanation !
I think it would be good to include it in the documentation.
Your explanation related to the identification of the line which raise the hardware fault leed me to the idea if it would be a good idea to integrate this task into the IDE.
It is not a big deal to make it by hand but for new customer it would be nice additional feature.
And if I understand your explanation correctly it would not be so difficult to implement it.

Best regards

Andreas