This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to trace the root cause of HardFault Cortex M3 with .lst file?

Dear All,

Now I'm trying to trace the root cause of HardFault Cortex M3 with .lst and tarmac0.log files.

Currently problem is that I'm not sure how to trace the root cause when I come across HardFault.

In especially, I'm wonder that does disassembly code help us to trace the root cause?

 UartPutc((char) DBG_ESCAPE); //send ESCAPE code
     2da:       201b            movs    r0, #27
     2dc:       f000 f8aa       bl      434 <UartPutc>
  UartPutc((char) DBG_CONNECT_ENABLE); //send debug test enable command
     2e0:       2011            movs    r0, #17
     2e2:       f000 f8a7       bl      434 <UartPutc>
  puts("\nEnabling debug tester...\n");
     2e6:       4810            ldr     r0, [pc, #64]   ; (328 <EnableDebugTester+0x60>)
     2e8:       f000 fa8e       bl      808 <puts>
  // If debug tester is not present,
  if((CMSDK_GPIO0->DATA & DEBUG_ERROR) != 0)
     2ec:       6823            ldr     r3, [r4, #0]
     2ee:       045b            lsls    r3, r3, #17
     2f0:       d405            bmi.n   2fe <EnableDebugTester+0x36>
  // (Zero the 4 words above Stack Top)
  //

  for(i=0; i<4 ; i++)
    {
  puts("\nInitialise the Communication Region...\n");
     2f2:       480e            ldr     r0, [pc, #56]   ; (32c <EnableDebugTester+0x64>)
     2f4:       f000 fa88       bl      808 <puts>
      DEBUGTESTERDATA[i] = 0;        //<================================HERE
     2f8:       2300            movs    r3, #0
     2fa:       681b            ldr     r3, [r3, #0]
     2fc:       deff            udf     #255    ; 0xff
  UartPutc((char) DBG_CONNECT_ENABLE); //send debug test enable command
  puts("\nEnabling debug tester...\n");
  // If debug tester is not present,
  if((CMSDK_GPIO0->DATA & DEBUG_ERROR) != 0)
    {
      puts("DBGERROR bit (debug error) asserted.\n");
     2fe:       480c            ldr     r0, [pc, #48]   ; (330 <EnableDebugTester+0x68>)
     300:       f000 fa82       bl      808 <puts>
      puts("Debug tester not available:\n");
     304:       480b            ldr     r0, [pc, #44]   ; (334 <EnableDebugTester+0x6c>)
     306:       f000 fa7f       bl      808 <puts>
      puts("1: The ARM_CMSDK_INCLUDE_DEBUG_TESTER macro is not defined, or\n");
     30a:       480b            ldr     r0, [pc, #44]   ; (338 <EnableDebugTester+0x70>)
     30c:       f000 fa7c       bl      808 <puts>
      puts("2: Cortex-M0 DesignStart is used\n");
     310:       480a            ldr     r0, [pc, #40]   ; (33c <EnableDebugTester+0x74>)
     312:       f000 fa79       bl      808 <puts>


As you can see the above code, I come across "Unexpected Hard Fault", when DEBUGTESTERDATA[i] = 0; run after.

Would you help me what am I supposed to do to resolve this problem?

Parents
  •       DEBUGTESTERDATA[i] = 0;        //<================================HERE
         2f8:       2300            movs    r3, #0
         2fa:       681b            ldr     r3, [r3, #0]
         2fc:       deff            udf     #255    ; 0xff
    

    The "udf #255" will generate an "undefined instruction exception" (part of the Usage Fault)
    If the Usage Fault is not enabled, it will generate a Hard Fault.

    This is clearly being done on purpose so you either need to enable the Usage Fault Handler and handle this undefined instruction or Handle it in the Hard Fault Handler.

    You are likely using other code (linking in) that is counting on a certain behavior when the udf #255 instruction is being executed and it is not happening so you get a hard fault rather than proper behavior.

Reply
  •       DEBUGTESTERDATA[i] = 0;        //<================================HERE
         2f8:       2300            movs    r3, #0
         2fa:       681b            ldr     r3, [r3, #0]
         2fc:       deff            udf     #255    ; 0xff
    

    The "udf #255" will generate an "undefined instruction exception" (part of the Usage Fault)
    If the Usage Fault is not enabled, it will generate a Hard Fault.

    This is clearly being done on purpose so you either need to enable the Usage Fault Handler and handle this undefined instruction or Handle it in the Hard Fault Handler.

    You are likely using other code (linking in) that is counting on a certain behavior when the udf #255 instruction is being executed and it is not happening so you get a hard fault rather than proper behavior.

Children