• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 40 subscribers
  • Views 864 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.

hard fault in CC3200 I2C

dj42901
Expert 1270 points

I am getting intermittent hard faults down in driverlib i2c.c I2CMasterIntStatusEx,

where it's doing return(HWREG(ui32Base + I2C_O_MMIS));

In disassembly this is:

20018d84:   6940     LDR             R0, [R0, #20]

R0 is 0x40020000, the register offset of 20 is right.

When this hard faults, my app has been running, happily chatting over I2C to my RTC chip, at least dozens of times.

What can cause a hard fault reading the I2C register?

Each time I do an I2C operation I am opening and closing the I2C peripheral, so I am certain that this read or write operation is

enlosed in:

I2C_IF_Open which does

    MAP_PRCMPeripheralClkEnable(PRCM_I2CA0, PRCM_RUN_MODE_CLK);
    MAP_PRCMPeripheralReset(PRCM_I2CA0);

and I2C_IF_Close which does:

    MAP_PRCMPeripheralClkDisable(PRCM_I2CA0, PRCM_RUN_MODE_CLK);

What else besides preipheral clock off could cause a hard fault reading a peripheral register?

  • 0
    TI__Guru 64365 points

    Hello,

    Hard to tell what could be the root cause but some preliminary questions:

    • what SDK are you using? is it the latest 1.2.0?
    • how often does it happen? have you observed any clue on when it happens or is it completly random?
    • What happens if you are not enabling/disabling the clock each time you try to I2C transact? can you do it only one-time and check?
    • what if you call other I2C API such as I2CFIFOStatus(), do you see the same phenomenon?
    • lastly, do you get an error when you call to MAP_I2CMasterErr(I2C_BASE)?

    We will inquire it internally for further debugging.

    Regards,

    Shlomi

  • 0
    Expert 1270 points
    Well, it looks like the answer is probably having the peripheral clock off causes the hard fault.
    Even though I start each transaction with I2C_IF_Open which enables the clock, because my I2C operations were badly distributed across tasks (I am using FreeRTOS), a higher priority task could interrupt an I2C operation, do its I2C thing, and disable the clock, then return to the other task's I2C operation in progress, but now the clock is off. Removing the clock disable from the close seems to fix it, though of course this means a power cost because now I am running the clock whether I am using the peripheral or not.
  • 0 in reply to dj42901
    Guru 39650 points
    Hi,

    Just a small suggestion. If you need more efficiency in your I2C transfers do not use I2C_IF_ wrapper form \example\common\. Efficiency of this code is poor. Better is use interrupts from I2C peripheral or even use DMA with I2C.

    Jan
  • 0 in reply to dj42901
    TI__Guru 64365 points

    Hello,

    Good catch. Thanks for the analysis and suggestions.

    Regards,

    Shlomi