• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 805 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.

Hercules RM48L952ZWT I2C Driver and Delay to Avoid Stuck in While loops

Tammy Noergaard
Genius 3665 points
Other Parts Discussed in Thread: HALCOGEN

Hello. We are using the RM48L952ZWT Hercules platform with HalCoGen 4.03.00. The I2C driver that had been generated using halcogen had problems, so in aother post on this forum we got another I2C driver to replace it (thank you). To use the I2C driver we used also the sample from TI (see below), where there is a 50msec delay between the transmission/reception of each byte (otherwise the driver gets stuck in the while loop because the I2C locks up).

i.e., in the

/* Wait until Bus Busy is cleared */
    while(i2cIsBusBusy(i2cREG1) == true);

    /* Wait until Stop is detected */
    while(i2cIsStopDetected(i2cREG1) == 0);

Why does it take 50msec? Is here anything we can do to decrease the delay time? Or will that be risky because then we end up in the endless while loop because of the lockup? WHen I decreased the delay, it does get stuck in the endless while loop. I just wanted to know if there is another way other than the delay between byte transmissions. Thank you.

  • 0
    TI__Guru 68920 points
    Hi Tammy, Hard to say without seeing the first post.

    50ms It sounds like it may be related to the timing on the I2C bus - and maybe the slow rise time that might appear on a pin.

    I don't know why exactly there is a hazard between these two function calls though .. that would need a 50ms delay.

    Do you happen to have the original post?
  • 0 in reply to Anthony F. Seely
    Genius 3665 points
    Hi Anthony, I think there were a few over a year ago. One of them was e2e.ti.com/.../407879. I will look up the others as well. We never upgraded our HalCoGen to newer release because we were nervous about losing the HalCoGen bug fixes we got from TI from version 4.03.00. Thank you again.
  • 0 in reply to Tammy Noergaard
    TI__Guru 68920 points
    Hi Tammy,

    Looking at that post - Prathap's last posting shows the delay *after* the two status tests, not in between them..


    /* Wait until Bus Busy is cleared */

    while(i2cIsBusBusy(i2cREG1) == true);

    /* Wait until Stop is detected */

    while(i2cIsStopDetected(i2cREG1) == 0);

    /* Clear the Stop condition */

    i2cClearSCD(i2cREG1);

    /* Simple Dealya before starting Next Block */

    /* Depends on how quick the Slave gets ready */

    for(delay=0;delay<100000;delay++);



    And it looks like the driving need for this is time for the slave device to recover.


    Best Regards,
    -Anthony
  • 0 in reply to Anthony F. Seely
    Genius 3665 points

    Hi Anthony. Yes you are correct. We have had to sometimes have a delay of up to 50msec or it would get stuck in one of the while loops waiting to hear from the slave. Is this normal that it could take up to that long?   Thank you again.

  • 0 in reply to Tammy Noergaard
    TI__Guru 68920 points
    Hi Tammy,

    It could be normal - I can't say for sure though if it is a requirement driven by the slave device that you are communicating with as it appears from the earlier post. Sure there are slave devices that are low end and need a recovery time between commands.
    But I cannot tell you if that's the case for the particular slave device you are using. If it's a TI device we could find the right forum and ask.. .if it is another MFGR would need to ask them.

    Thanks and Best Regards,
    Anthony
  • 0 in reply to Anthony F. Seely
    Genius 3665 points
    Hi Anthony. Thank you. I have given the info to my manager/hardware team to look into using a different part (right now it is not a TI part). Thank you again.