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

I2C fails to work when P0_15, P0_16 is configured

On a custom pcb, an I2C sensor is connected on P0_15 and P0_16 ( SDA & SCL ).

When sensor reading is requested, the code is designed to wait till the reading is returned from the sensor. The code gets stuck waiting at this.

When browsing through the nRF52832 pin assignments, observed that the TRACEDATA pins are shared with P0_15, P0_16 ( https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fpin.html ).

Any suggestions on how to make sure that the pins are being used as I2C and not as TRACEDATA pins?

Parents
  • Hi,

    It is correct at Hugh mentions - you will need to enable trace functionality if the pins are going to function as trace. If you do not, they function as regular GPIOs.
    If you want to make sure that they are not configured to Trace, follow Hugh's instructions.

    When sensor reading is requested, the code is designed to wait till the reading is returned from the sensor. The code gets stuck waiting at this.

    This happens if you are not receiving anything from the TWI slave. Are you able to use an oscilloscope to see whether you have the appropriate output on your selected pins?
    This could either be caused by an incorrect configuration of the TWI master, or a faulty hardware connection.
    Is it just the sensor reading that fails, or is it the setup/initialization of the sensor that fails? - By this I mean, is there any successful TWI communication at any time?

    Are you working out of an example, such as the TWI_sensor example, or are you making use of the TWIM API Reference directly?

    Best regards,
    Karl

Reply
  • Hi,

    It is correct at Hugh mentions - you will need to enable trace functionality if the pins are going to function as trace. If you do not, they function as regular GPIOs.
    If you want to make sure that they are not configured to Trace, follow Hugh's instructions.

    When sensor reading is requested, the code is designed to wait till the reading is returned from the sensor. The code gets stuck waiting at this.

    This happens if you are not receiving anything from the TWI slave. Are you able to use an oscilloscope to see whether you have the appropriate output on your selected pins?
    This could either be caused by an incorrect configuration of the TWI master, or a faulty hardware connection.
    Is it just the sensor reading that fails, or is it the setup/initialization of the sensor that fails? - By this I mean, is there any successful TWI communication at any time?

    Are you working out of an example, such as the TWI_sensor example, or are you making use of the TWIM API Reference directly?

    Best regards,
    Karl

Children
No Data
Related