• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 365 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.

AM3358: I2C programming for the PRU

Michael Crum
Prodigy 10 points
Part Number: AM3358


Hi all,

I'm working on a driver for I2C on the AM3358 running on a pocketbeagle. I've been writing my code based on this library on github for the am572x, making the relevant changes to play nice with the am3358.

My code is here. The sensor I'm using is confirmed to work on the hardware when accessed from the ARM side (running Linux).

My code gets stuck polling the busy bit, which never clears. Any ideas for what I might be doing wrong?

Couple of other questions about the pins:

I've seen other posts mentioning pin muxing, specifically that I need to disable I2C on the ARM side so that it doesn't interfere with PRU operation. I can't seem to mux the I2C2 pins to be explicitly used for the PRU, only as I2C or GPIO. Is muxing them to GPIO sufficient? Another post also mention disabling I2C in the Linux device tree, is that necessary?

Should I even be using the normal I2C2 pins that I've been using on the Linux side? Or are there specific pins for the PRU I2C interface?

Any help would be greatly appreciated! 

  • 0
    TI__Guru** 105540 points

    Hello Michael,

    We do not perform code reviews on this forum. However, if you have a specific question about a specific line of code, feel free to ask and I can take a look.

    Based on the AM57x library you linked, I assume that you are connecting the I2C external device to one of the Processor I2C instances? In that case, you would want to pinmux the signals to go to the I2C instance. Then the PRU would communicate with the I2C instance. Your other option would be to connect the I2C external device directly to the PRU GPI / GPO signals. However, in that case you would need to implement the I2C protocol in your PRU firmware since there would not be dedicated I2C hardware implementing the protocol.

    In general, we suggest that a certain peripheral should be controlled by only one processor core. So if a specific I2C instance was controlled by the PRU cores, then we would suggest that the I2C instance should be disabled in the Linux device tree so that the Linux ARM core does not mess with the peripherals controlled by the PRU. Note that the PRU does not have permissions to modify the padconfig registers, so pinmuxing will still occur in the Linux devicetree. Also note that a peripheral's clocks may not be enabled by default if the peripheral is disabled in the Linux devicetree, so you may need to enable the peripheral clocks manually.

    Regards,

    nick