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 RTOS BLE context: issue sharing bus for MMA865X and KXTF9-4100

Hello,


I am working on an RTOS  BLE application.

I defined all components to use standard I2C.

Over this bus the sensor KXTF9-4100 works fine.

Whilst I connect also the other (MMA865X) both do not

work as expected.

They have different address (0x0F and 0x4A).

The MMA865X accelerometer does not work.


Welcome any advice...

Thanks

  • Hello Misteralex,

    Could you explain with more detail what you mean by "the accelerometer doesn't work"? Are you getting a NACK from the device?

    It would be helpful if you could post screen shots from an oscope of the I2C waveform, so we can start to narrow down where the issue is.

    It is my understanding that you have 2 sensors on your I2C bus only, a KXTF9-4100 and a MMA865X. When you have only 1 connected, communication works with no issues. Once you connect both to the same bus, communication does not work to either. Can you confirm if this is the case?

    Also, could you supply a block diagram/schematic showing your I2C bus. I am interested in your I2C devices connection to the bus and pull-up resistors.
  • Hello Jonathan,

    thanks for your fast reply.

    First of all, my goal is using the MMA865X sensor alone. But it gives issues and I am testing

    same configuration but with other hardware that include the other sensor in the same I2C

    bus. This test provides first confirme that the application over I2C bus works as expected in

    RTOS/BLE context.

    The application use I2C TI design already proposed for SensorTag project.

    After standard init() and open() setting I check each device trying to write a register

    and after calling standard WHO_AM_I query.

    1) KXTF9-4100 sensor

        Default address 0x0F, WHO_AM_I register 0x0F

        1.1) sensorWriteReg() write successfully

        1.2) sensorReadReg(WHO_AM_I, &val, 1);

                 give value 0x01. The expected response for this type of Kionix sensor

        1.3) I see expected clock from oscilloscope

    2) MMA865X sensor

        Default address 0x1D, WHO_AM_I register 0x0D

        2.1) sensorWriteReg() write error (never works)

        2.2) sensorReadReg(WHO_AM_I, &val, 1);

        2.3) I cannot see expected clock from oscilloscope

                 read error (never works)

        2.4) I cannot see expected clock from oscilloscope

    I suppose we have an hardware issue whilst the application works fine with the I2C KXTF9-4100

    sensor and does not provides expected behavior when I connect the MMA865X sensor.


    The same issue is shown within hardware design that include ONLY this last sensor over I2C.

    Please let me know your thoughts.

    Here in attachment a typical application circuit used for our MMA865X.

    Thanks

  • MisterAlex,

    You state that you do not see any clock data at all. Does the line just sit idle at a high voltage or low voltage? Do you see any strobing of the clock at all?

    If you see any strobing on the SDA and SCL lines (Even if not what you expect), can you take a picture on scope and upload it?
  • Hello,

    I see clock data when I use the KXTF9-4100 sensor. Further, It works as expected as already described.

    When I connect over there also the MMA865X sensor anything work (including the KXTF9).

    In all cases clock line sit at high voltage and when it works (only KXTF9 connected) I see strobing from

    clock line.

    Further, considering same application and a board design that include ONLY the MMA865X sensor with standard

    electrical configuration already posted, the device does not works. It open properly the I2C bus, provide an handle but it does

    not read/write registers as already described. No strobing from clock line over there.

    Thanks for your support.

  • The MMA865X works as expected with standard electrical configuration when it is the only device on the bus. It was an address issue there. It still does not work in the other test case but I do not care about it. Problem solved.