• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 42 subscribers
  • Views 600 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.

Original question:

CC3235MODSF: CC3235MODSF: cc3235 - i2c slave - no TX_FIFO_EMPTY IRQ happens when flag is set.

CC3235MODSF: CC3235MODSF: CC3235MODSF: cc3235 - i2c slave - no TX_FIFO_EMPTY IRQ happens when flag is set.

user6378938
Expert 1200 points
Part Number: CC3235MODSF
Other Parts Discussed in Thread: CC3200

Please see the original post that got locked: e2e.ti.com/.../3503174

Then the thread opened from that issue got locked too: e2e.ti.com/.../964175

Still waiting for an answer.

  • 0
    TI__Mastermind 38980 points

    Hi user6378938,

    As my colleague mentioned, we do not officially support I2C slave drivers in our CC32xx SDK. I apologize for the delay on this, but at this time we're not planning to develop the I2C slave driver further or add testing for it. I'm able to point to solutions that other customers have posted to this forum, but I'm not sure if they apply to your particular issue. Are you able to workaround this issue or switch to I2C master?

    Best regards,
    Sarah

  • 0 in reply to Sarah P
    Expert 1200 points

    This issue was reported against the CPU periphery and not the driver (driver does not exist).

    For months now I am waiting on an answer.

    Someone kept this thread alive with stating he will recreate the problem, even promised that (after delaying for months) it will be worked on after the holiday season.

    Please state if the I2C SLAVE periphery is not supported by TI CC3235 and it exists in the swru543_Technical_Reference_Manual.pdf by accident or it this is a supported periphery.

  • 0 in reply to user6378938
    TI__Mastermind 38980 points

    Hi,

    I understand your frustration, but I want to set the expectation for how this feature is supported. We have had customers implement their own drivers to use this peripheral, but we do not have I2C slave drivers that we test in our quarterly SDK updates. I see that my colleague may have been looking into this before. I will meet with him to see if he has any progress on your issue and we will follow-up next week.

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Expert 1200 points

    Thanks.

    I am also talking about developing my own driver.

    But I'm stuck at this point because it seems CPU IRQ is not handled properly(?)

  • 0 in reply to user6378938
    TI__Mastermind 40965 points

    Hi,

    I've looked into the I2C registers and functionality, and have found some paths forward for you to explore. As my colleague Sarah explained, we do not have an official I2C slave driver, and so do not have a ready-made example of how to use the I2C peripheral in slave mode on the CC32xx devices.

    Still, there are resources online that implement similar functionality to what you're looking to do. The main example being the I2C code in this thread here:

    https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/415116

    While the code in that thread deals with the I2C peripheral in master mode, the FIFO functionality and register manipulation looks to be just about the same for what the peripheral expects in slave mode. Looking at its interrupt handler that is shown at the end of the thread (not the one in the opening post), it seems that the way to handle TX FIFO requests is to check for either the TXRIS OR the TXFERIS condition. On either condition, you clear both interrupts, and then load the TX FIFO back up. Most crucially, it seems that the interrupt handler does not rely on getting the TXFERIS condition at all, instead counting the number of bytes sent to see if the TX is complete.

    If you look at the interrupt handler provided in that thread and modify your code to use its flow, are you able to TX with your I2C slave code?

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Expert 1200 points

    How is this related to the CPU bug I reported posts ago please?

  • 0 in reply to user6378938
    TI__Mastermind 40965 points

    Hi,

    The information presented in my previous post is what I had discovered and suggested you use in the interest of saving your time. As I'm sure you want to resolve this issue as quickly as possible, getting a good configuration for the I2C peripheral and adapting it to a I2C slave use case would be more straightforward than pursuing the TXFERIS behavior.

    Given that we have provided a workable solution to setting up I2C functionality on the CC3235, we will no longer be investigating the TXFERIS behavior, as it is not needed for the method I provided in my previous post.

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Expert 1200 points

    "provided a workable solution"

    This sums up. E2E forum and TexasInstruments support in a nutshell.

    Waiting 4 months after reporting a probable I2C _SLAVE_ CPU bug where I POSTED WORKING SAMPLE CODE:

    1) no one reproduces it or even tried out

    2) one app engineer answers after another 

    3) they all refer to a completely different thread that handles MASTER mode and contains sample code... maybe that helps

    4) lets call it a solution and close the thread

    Thanks. Lesson learned. My colleagues warned me about E2E. I kept insisting it is not, can not be like that, I kept giving a chance.

    Today I'm done, gutted.

    Really can't find words for what this discussion was. 4 months of discussing and repeating myself leading to "a master sample code and the resolution is 'get the **** out and solve it yourself'".

  • 0 in reply to user6378938
    Guru 79985 points

    Hi,

    I am in independent developer and I have no relationship to TI. We use TI products in our devices and from this come my experiences with CC32xx devices.

    We had used I2C slave peripheral with our older design with CC3200. This peripheral is same at CC3235 as well. Yes, I agree that there are some issues with this peripheral, but nothing serious. I think Michael pointed you to right solution of issue. If you don't want to follow their recommendation, it sounds me like you don't want solve problem actually. But I don't want judge your motivation.

    (btw ... your impolite comments at your other threads is not a best approach to motivate other users with solving your issue)

    Jan

  • 0 in reply to Jan D
    Expert 1200 points

    Thanks. I usually first ask and try to supply as much and as thorough, detailed info as possible to give a clear impression of my standing point, what is the issue, how to reproduce and what I tried possibly as workaround.

    And after weeks/month of waiting my threads gets closed without an answer.

    When I reopen them the whole process of dumm questions appear "why do you need that?" "just use SPI/something else" "it was not meant to be...".

    I would assume that when someone takes the time and effort to collect that amount input and posts a detailed thorough information, such questions do not gets asked from the beginning and we start focusing on the issue itself.

    Secondly, the Technical Reference Manual details the behavior of the I2C peripheral. This chip is released by TI so there is no excuse saying "sorry we don't support slave drivers". I have never talked about slave driver. I was always talking about the CPU and the peripherals itself. I think it is clear that at this point they could tell me "sorry, we looked into that, errata will come out soon" or "oh try DMA approach, we can help you with that as the datasheet is at the moment in such a draft state". 
    So far I only read "no slave driver is supported" and "check out master examples".

    Sorry being impolite but this if you read back in every thread was not my starting attitude. As written above I always tried to approach issues as professionally as possible. It was a reflection to being handled in such a condescending childish way I feel always feel after reaching the "if giving 3 _replies_ to a thread does not answer lets close the thread" 'resolution'.

    I will now close this discussion from my side. I escalated this and other threads as example to our management and they will decide how to deal with the situation.