Skip to main content
Visitor II
May 6, 2018
Question

STM8L I2C

  • May 6, 2018
  • 3 replies
  • 2170 views
Posted on May 07, 2018 at 00:51

Hello, i have a STM8L Discovery board with a stm8l152C6T6 microcontroller. I'm currently trying to communicate with a M24LR04E (NFC) board through an I2C connection.

I've done some tests using the 'generateStart' function, that appears to be working fine:

  1. I2C_GenerateSTART

    (

    I2C1

    ,

    ENABLE

    )

    ;

      
  2.      

    while

    (

    !

    I2C_CheckEvent

    (

    I2C1

    ,

    I2C_EVENT_MASTER_MODE_SELECT

    )

    )

    ;

 

However, when trying to send data to the board through 'send7bits' function, my code get stuck on the next 'while' construction without any apparent reason:

  1. I2C_Send7bitAddress

    (

    I2C1

    ,

    (

    uint8_t

    )

    I2C_Slave_Adress

    ,

    I2C_Direction_Receiver

    )

    ;

  2.      

  3. while

    (

    !

    I2C_CheckEvent

    (

    I2C1

    ,

    I2C_EVENT_MASTER_RECEIVER_MODE_SELECTED

    )

    )

    ;

    //This while never stops

Additionally, I've tried other examples available through ST documentation ('I2C EEPROM' / 'I2C TWOBOARDS') without success.

Any clue regarding what is happening will be very appreciated.

Thanks!

The complete source code: 

https://pastebin.com/rWdKa06s

Circuit :

https://imgur.com/a/xHU4z5T

// The jumper has been set on

#i2c #eeprom #m24lr04e-r #stm8l-discovery #nfc
    This topic has been closed for replies.

    3 replies

    Visitor II
    June 14, 2018
    Posted on June 14, 2018 at 08:06

    Hi everyone, I have the same issue here. I am trying to use the MAX44009 i2C sensor and I am also stuck inside the same loop.

    This function I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED) always return 0 and keep the while loop looping.

    I put some UART printf inside the for loop to check the event and it always outputs 0:

    while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED))

    {

    printf('%d ',I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED));

    printf('%d\n',I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_RECEIVER_MODE_SELECTED));

    Delay(10);

    }// 0 0 forever

    Thanks for any help in advance!

    Visitor II
    June 14, 2018
    Posted on June 14, 2018 at 09:37

    Problem partly solved, it is because the address is not the correct for my case.

    You need to manually shift the slave address by 1 for the function:

    void I2C_Send7bitAddress(I2C1,addr << 1, I2C_Direction_Trasmitter);

    I think there is a huge room of improvement for the documentation of the library...

    Credit to:

    https://community.st.com/0D50X00009XkYkzSAF

    Visitor II
    June 14, 2018
    Posted on June 14, 2018 at 12:07

    '

    You need to manually shift the slave address by 1 for the function'

    that's often the case with i2c addresses. I usually just use 8-bit address notation with the last bit being write/read command.

    Graduate II
    June 14, 2018
    Posted on June 14, 2018 at 12:51

    That, and a lot of the I2C documentation for the parts is inconsistent. If I'm unsure I go to the documentation because even when they quote the address as number they usually describe the bitmapping in a table somewhere else, explicitly showing the bits on the wire for a read or write. The confusion is usually because the 7-bit address is the 7 most significant bits and the R/W flag the least significant bit.

    Visitor II
    June 14, 2018
    Posted on June 14, 2018 at 12:58

    I read though the data sheet of the sensor and the example of the SPL. To be honest , when I see there is a parameter for transceiver and receiver, I automatically think the library will shift the bit for me...

    Graduate II
    June 14, 2018
    Posted on June 14, 2018 at 13:38

    >>I automatically think the library will shift the bit for me...

    I think ST has a 10+ year history of not doing that. My experience across ATMEL, PHILIPS, NXP, TI, etc are mixed, one of the things you have to double-check, and thankfully I2C alerts you when you're not seeing the device on the bus responding, either because the address is wrong, or the device isn't populated/connected.