• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 338 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CCS/TM4C123GH6PZ: CORTEX_M4_0: Trouble Reading Memory Block at 0x40050006 on Page 0 of Length 0x2: Debug Port error occurred...

TM4C123GH6PZ: how can i trace back the line of code triggerring exit

Yao Aili
Intellectual 330 points
Part Number: TM4C123GH6PZ

Hi TI：

   When i debug TM4C123GH6PZ，sometimes the chip enter abort（） function；

   I know there is some problem with the code， how can i trace back to the line of code with error？

Thanks

  • 0
    Intellectual 330 points

    it shows Hard Fault: FORCED: BUSFAULT: IMPRECISERR

  • 0 in reply to Yao Aili
    TI__Guru 72500 points

    Typically this fault occurs when you write to a peripheral for which you have not yet enabled the clocks. Often C stepping through your source code will help you identify which peripheral that is. For more details on diagnosing bus faults see:

    http://www.ti.com/lit/an/spma043/spma043.pdf 

  • 0
    Guru 117855 points

    Greetings,

    Yao Aili said:
    how can I trace back to the line of code with error？

    Depending upon the extent & complexity of your code - often it proves helpful to, "Divide your code into multiple, smaller sized sections."   You then "independently" run & test (again only one) of each of these sections at a time.   The reduced size of these "code sections" enables you  to most always, "Speed, Ease & Enhance" your "traced-back detection" of the problem!

    You should seek to confine your "sections" to complete code-blocks (multiple code-blocks are possible) - so that each section includes that necessary to execute properly.

    It is my firm's (proven) belief that code should be developed in small/methodical "blocks" - with each block being individually tested & verified - prior to being, "Integrated w/in the general program.    This progressive, code development method is noted as, "KISS" - and for decades has proven immensely empowering.    (even though - especially though - "KISS" never is credited (nor sees the "light of day") here...)

    After you've identified the "problem section" (hopefully just one section) the vendor's "MCU-centric" guidance should provide high/specific code detail - made far more efficient due to the, "Reduction in Code Size being "specific tested."

    Reducing an issue's, "Size & Scope" (KISS) proves a classic method to, "Greatly Enhance Diagnostic Success!"