I2C Slave NUCLEO-F411RE

[dae]

Hello, 

I am currently working on a project where I need to configure a NUCLEO F411RE Board as an I2C slave. It will be connected to a Raspberry Pi Master.

I am able to detect the NUCLEO on the raspberry Pi, however I am unsure how to get the read byte. I created a simple code where when the byte received is 0x01 or 0x10 the LED should turn on, if it receives anything else it turns off. However this doesn't seem to be working.

This is the code I am using:

uint8_t buffer[0];

for (;;)

{

HAL_I2C_Slave_Receive(&hi2c1, (uint8_t *)buffer, sizeof(buffer), HAL_MAX_DELAY);

if ((*buffer == 0x01)|| (*buffer == 0x10)){

HAL_GPIO_WritePin (GPIOA, GPIO_PIN_5, GPIO_PIN_SET);

HAL_Delay (100);

}

else{

HAL_GPIO_WritePin (GPIOA, GPIO_PIN_5, GPIO_PIN_RESET);

HAL_Delay (100);

}

}

If anyone can help me with this issue, it would be greatly appreciated. (I am sending a 0x01 on the Raspberry Pi side)

[Andrew Neil]

---

@dae wrote:

this doesn't seem to be working.

---

You need to give more details.

What pullups are you using.

What, exactly, is happening? 

Have you looked at the I2C lines with an oscilloscope to check that the signals are good?

What do you see when you step the code?

HAL_I2C_Slave_Receive() returns a status code - you should check what it is.

Does your RPi think the transfer succeeds?

I'm sure ST have examples using I2C Slave mode - have you tried them?

Use this button to properly post source code:

To get that extra row of icons, press this button:

[SofLit]

Hello,

You need also to provide your I2C configuration to let others help you efficiently.

How about your connections with Raspberry Pi? your HW? Pull-up resistors?

PS: you can inspire from the example provided in STM32CubeF4 located under Projects\STM32F411E-Discovery\Examples\I2C\I2C_TwoBoards_ComIT

[dae]

The raspberry pi has its own internal pull ups.

The code always seems to be in the "else condition" meaning that it never receives a 0x01 byte.

I have checked that the Raspberry Pi is in fact sending the correct byte to the correct address.

For the hardware setupt, I am connecting the SDA and SCL lines and Ground between the two boards.

I have used the ST example in slave mode, and it did not fix my issue.

Thank you for your help!

[dae]

Hello,

I am using a basic I2C Configuration as seen in this screenshot. The connection to the Raspberry Pi is simply wires connecting SDA, SCL and GND Pins. The Raspberry Pi has its own pull up resistors.

I will check out the example provided, thank you! 

[Andrew Neil]

---

@dae wrote:

I have checked that the Raspberry Pi is in fact sending the correct byte to the correct address.

How did you check that?

Does the RPi think that the transmission was successful; ie, does it think that it gets an ACK ?

HAL_I2C_Slave_Receive() returns a status code - you should check what it is.

Have you looked at the I2C lines with an oscilloscope to check that the signals are good?

---

@dae wrote:

The code always seems to be in the "else condition" meaning that it never receives a 0x01 byte.

---

So what value does it receive?

[SofLit]

---

I am using a basic I2C Configuration as seen in this screenshot. The connection to the Raspberry Pi is simply wires connecting SDA, SCL and GND Pins.

You need to check the wire continuity between the two boards (SDA, SCL and GND) , it could be also something related to the wires themselves ..

[dae]

I have checked using the Oscilloscope that the Pi is sending bytes correctly.

The Pi doesn't check for an ACK it just keeps transmitting a 0x01 byte.

The status code returned is HAL_BUSY

The value received seems to always be 0 

[Andrew Neil]

---

@dae wrote:

I have checked using the Oscilloscope that the Pi is sending bytes correctly.

---

So you should be able to see if the transfer ends with an ACK ?

---

@dae wrote:

The Pi doesn't check for an ACK it just keeps transmitting a 0x01 byte.

---

It should!

---

@dae wrote:

The status code returned is HAL_BUSY

---

Then it didn't receive anything - so there is no point in trying to do anything with the received data.

Have you tried stepping into HAL_I2C_Slave_Receive() to see what, exactly, makes it give that code?