• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 792 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2640: Bus fault after random number of packets received to cc2640

Mujahid Abbas
Expert 2860 points
Part Number: CC2640
Other Parts Discussed in Thread: BLE-STACK

Hello,

I am using simple peripheral application on cc2640 with ble stack v2.2.1. The cc2640 is connected to other MCU through I2C interface. cc2640 is slave in I2C.

I am trying to test the BLE FW with android application. I am sending 500 ble packets from android application to cc2640.

The cc2640 often shows the bus fault after random number of packets (some time 200,100,140) from the android device. Some times it gets the all packets successfully.

The bus fault is occurring due the overclocked chip  and accessing invalid address.


I have post the screen shoots in my second comments for details. 

Waiting for your kind help.

  • 0
    Expert 2860 points

    Hello,

    I tried to debug the problem and found at IAR  https://www.iar.com/support/tech-notes/debugger/debugging-a-hardfault-on-cortex-m/ about bus fault.

    I saw the values of the registers when bus fault occurs. Following are the register values when the bus fault occurs:

    These values matches the first case described in the above IAR link. According to that  Overclocked Chip. 

    The most of the time when bus fault occur it is due to chip over clocked. Could you tell me what is mean by overclock? How i can solve the overclocked issue?

    Sometimes the the bus fault occurs due to the Accessing an invalid address (see the above given IAR link).

    Following is the screen shoot of register when bus fault occurs:

    Please help me to find the solution of the problem.

    waiting for your kind help.

  • 0 in reply to Mujahid Abbas
    TI__Mastermind 33460 points

    Hello,

    I would disable write buffering to ensure IMPRECISERR is always forced to PRECISERR.

    We have an example of how to do this in our debugging chapter of the ble-stack user's guide. (another good debugging reference by the way).

    It appears based on your second capture that something is trying to write outside of the valid RAM region of the chip. What I would recommend is setting a watchpoint on this address and breaking when it is written to.

  • 0 in reply to Sean2
    Expert 2860 points
    Hi Sean,

    The issue is resolved i disabled the write buffering. There was a bug in application that tries to copy data from an invalid memory location.