This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to enable ETM trace in nRF52 PCA10040 board

Hi,

I am facing hardfault when i try to enable low power in a ble application. i want to enable trace on my PCA10040 board to find out the cause of this hardfault. can you help me to succeed to enable trace ? please.

Best regards.

Parents
  • Unfortunately, the j-link plus does not appear to support trace. Does the call stack provide any clues as to what function caused the hardfault? I.e, are there any function calls on the stack prior to the hardfault? You can also get the PC value before the exception occurred by reading the memory at the current stackpointer pluss an offset of 24 bytes (SP+24).

    Also you can just insert breakpoints and determine how far the application gets before the exception occurs. With this you should be able to locate the code that triggers it.

    EDIT - Attached screen dump for illustration

    The function call prior to the exception will generally be shown if it occurred in the application code. Also see that the address of the instruction that caused the hardfault is loaded to R0, but not sure if that is always the case.

    To illustrate this I triggered a hardfault exception by accessing an invalid memory area in the battery_level_update function found in the hrs example.

    1. dummy pointer to 0x8000000 which will cause hardfault when the cpu tries to fetch the content in the battery_level_update function.
    2. SP value pushed to stack prior to entering the event handler.
    3. problem function
    4. PC counter
    5. Same address to function call as shown in the memory view (4).

    image description

    You can download the image to enlarge it.

Reply
  • Unfortunately, the j-link plus does not appear to support trace. Does the call stack provide any clues as to what function caused the hardfault? I.e, are there any function calls on the stack prior to the hardfault? You can also get the PC value before the exception occurred by reading the memory at the current stackpointer pluss an offset of 24 bytes (SP+24).

    Also you can just insert breakpoints and determine how far the application gets before the exception occurs. With this you should be able to locate the code that triggers it.

    EDIT - Attached screen dump for illustration

    The function call prior to the exception will generally be shown if it occurred in the application code. Also see that the address of the instruction that caused the hardfault is loaded to R0, but not sure if that is always the case.

    To illustrate this I triggered a hardfault exception by accessing an invalid memory area in the battery_level_update function found in the hrs example.

    1. dummy pointer to 0x8000000 which will cause hardfault when the cpu tries to fetch the content in the battery_level_update function.
    2. SP value pushed to stack prior to entering the event handler.
    3. problem function
    4. PC counter
    5. Same address to function call as shown in the memory view (4).

    image description

    You can download the image to enlarge it.

Children
Related