• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 83 subscribers
  • Views 695 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28035: SPRUFZ9D Datasheet confusion on BB bit

ngohara1991
Intellectual 555 points
Part Number: TMS320F28035

Hello,

I have some confusion about the busy bit as described in SPRUFZ9D.

It appears that the datasheet conflict whether BB is cleared by IRS. Page 29 indicates  BB cleared by 'I2C module reset', but page 30 indicates BB keeps its state through IRS=1-to-0-to-1 transition.

Can someone confirm for me which is true?

Thank you

Neal

  • 0
    Guru 30330 points
    Neal,

    You are correct there is some confusion here. We are looking into this. I should be able to provide a solid response tomorrow.

    Thanks,
    Mark
  • 0 in reply to Mark Labbato
    Intellectual 555 points
    Hello Mark,
    thank you for the assistance.
    Has there been any progress on this investigation?
    I don't wish to nag, but I am rewriting my companies' confusedly written I2C driver and this bit has some relevance, as you might imagine.
    Sincerely
    Neal
  • 0 in reply to ngohara1991
    Guru 30330 points
    Neal,

    I am still looking into this. I believe that the bit description describes the correct behavior based on some testing. But i have lingering questions which I am seeking confirmation of.

    I will press for a response. it may take a few days for confirmation though.

    -Mark
  • 0 in reply to Mark Labbato
    Intellectual 555 points
    Hello Mark,
    Has there been any update to this issue?

    Also, to clarify something.
    If the BB is read as high, is there a recommendation for how long the master should wait (to determine if stuck rather than in transfer)?
    If IRS=0 does clear the BB, then is resetting the correct response when the BB is 'stuck' high for an arbitrary longer-than-message-propogation-time delay?

    Should SCD (the stop bit status) be used at all when determining if BB is an error, and if so can you recommend how?

    Thank you for the assistance.
    Neal
  • 0 in reply to ngohara1991
    Guru 30330 points
    Neal,

    I am still waiting on a reply. I have requested an update. Sorry for the delay here. Without the clarification I am seeking, I cannot answer your new questions yet. I'll let you know as soon as I have an update.

    -Mark
  • 0 in reply to Mark Labbato
    Guru 30330 points
    Neal,

    Just wanted to let you know that I will hopefully be able to get you some actual information by Thursday next week.

    I really appreciate your patience here.
    -Mark
  • 0 in reply to Mark Labbato
    Intellectual 555 points

    Hello Mark,
    It has been more than three weeks since the original post. May I ask what is going on behind the scenes that is delaying an answer regarding this peripheral's register operation?

    Thank you,
    Neal

  • 0 in reply to ngohara1991
    Guru 30330 points

    Neal,

    We have had some back and forth with the design team and wanted to fully understand the behavior. I2C is a pretty old module and it sometimes takes a bit to get these things up and looked at in depth. I appreciate your patience.

    Luckily, we have reached a clear understanding and will be updating the documentation with the following information.

    The Bit description of the Bus Busy bit (BB) is correct. the bit is cleared by the I2C Module being placed in reset (Clearing IRS to 0), or by receiving or transmitting a stop bit. The BB bit is set when a start bit is seen on the bus. 

    This is (as previously mentioned) is incorrectly contradicted by the paragraph ".. Therefore, the BB bit will remain in the state it was at when the peripheral was placed in reset...". The steps mentioned in the paragraph should be followed after the I2C is released from reset are valid and should be followed. The quoted sentence will be corrected in a future release of the documentation.

    to answer your followup questions:

    If the BB is read as high, is there a recommendation for how long the master should wait (to determine if stuck rather than in transfer)?

    We do not provide a specific time period to wait other than the longest expected message duration as covered in the paragraph steps. 

    If IRS=0 does clear the BB, then is resetting the correct response when the BB is 'stuck' high for an arbitrary longer-than-message-propogation-time delay?

    Yes, since clearing IRS to 0 resets the bit on your end. If the bus is truly held low by an external device, you will have to do some extra system handling to determine the cause and resolution as that will be application dependent. If some retry counter exceeds your threshold, a gross failure may be occurring.  

    Should SCD (the stop bit status) be used at all when determining if BB is an error, and if so can you recommend how?
    This could perhaps be used to determine if the BB is set in error. i.e. a stop condition is detected, and the BB is still set should not happen.

    The I2C is a pretty basic protocol and a lot of the error detection and handling is left to the user. it is difficult to manage generically without understanding the system and the problems that will be faced with multiple masters a bus. 

    Regards,
    Mark

  • 0 in reply to Mark Labbato
    Intellectual 555 points
    Thank you Mark,
    This resolves my original datasheet confusion issue, of how is BB reset.

    I will probably be asking a new question soon about my particular program, as BB and SCD and STP are not interacting like I thought they would. I hope you will be able assist when I do.
    Thank you for all the assistance so far,
    Neal
  • 0 in reply to ngohara1991
    Guru 30330 points
    Great. When you do, please use the "Ask a related question" button on the top of this thread to create a new thread but be linked together on our end!

    -Mark