1

This is driving me nuts for a couple of days now, so maybe you guys can give me some insights into what is going wrong.

I'm trying to read some data from an EEPROM (24LC16B) with an STM32(F0), but it just doesn't let me. I've tried an Arduino, which worked and does still work, so I do know that the wiring is correct.

This is my function to read the EEPROM data. (It is cut down to the very basis, just for testing): (Pastebin of my I2C_setup function)

uint16_t readEEPROMData(uint16_t deviceAddress, int memAddress){
    // Wait while I2C peripheral is not ready
    I2C_WaitForFlag(I2C_ISR_BUSY);

    // Start I2C write transfer for 2 bytes, do not end transfer (SoftEnd_Mode)
    I2C_TransferHandling(I2C1, 0xA2, 2, I2C_SoftEnd_Mode, I2C_Generate_Start_Write);
    I2C_WaitForFlag(I2C_ISR_TXIS);

    // For testing purpose, be sure to generate a stop command...
    I2C_TransferHandling(I2C1, 0xA2, 0, I2C_AutoEnd_Mode, I2C_Generate_Stop);

    return I2C_COMM_STATUS;
}

Here's an pastebin of the Arduino library I used.

I've used a logic analyzer to see how the communication is going, and now I really don't understand it. Here's a printscreen of the working Arduino version: Arduino EEPROM communication

And here's a printscreen of the STM32 communication: STM32 EEPROM communication

Logic analyzer exports (viewable with Saleae Logic)

As you can see, I'm using the same address (although I had to use 0xA2 with the STM32), and there are no weird things happening, besides the NACK. So what could possible be wrong?

Mathlight
  • 6,436
  • 17
  • 62
  • 107
  • 1
    I had also faced this kind of issue in past. Kindly conform that all timing requirement have been satisfied. Make sure previous write cycle was completed before initiation new command i.e. their should be at-least a delay of 5mS after previous write operation. Third issue can be regarding bus capacitance (which I faced). The capacitance on bus was distorting my waveform. – Dark Sorrow Jan 04 '18 at 15:35
  • @DarkSorrow Thank you for responding. The timing difference between the Arduino and STM is max a `.5 μ` for the SDA and SCL. There is a delay of 0.12s between each attempt, so that shouldn't be an issue to? – Mathlight Jan 04 '18 at 15:41
  • @DarkSorrow Could you elaborate more about the bus capacitance? – Mathlight Jan 04 '18 at 15:42
  • @DarkSorrow Thank you very much for pointing out the capacitance problem. I've tried the wires used with the Arduino, and although I had to hold them by hand onto the pins, I do receive some `ACK`'s now, instead of all `NACK`'s. So I also think that that's the case. I'm gonna try to make the wires stick and see how that turns out, but if you could make an answer with these points (especially the last one) that would be great – Mathlight Jan 04 '18 at 15:51
  • We had several devices on the same I2C bus. 2 of these devices where located on distance connected via a cable. Due to this cable bus capacitance increased causing distortion in the waveform. Of the connected devices EEPROM and a sensor was responding with NACK but when cable was disconnected the EEPROM started working properly. – Dark Sorrow Jan 04 '18 at 15:52

1 Answers1

2
  1. Confirm if all bus timing requirement are satisfied.
  2. Confirm if their is adequate delay after every write cycle (5 mS)
  3. Confirm is bus capacitance falls under permissible limit of I2C (400 pF - Theoretically).
  4. Confirm if the correct VCC is supplied

As mentioned by you are interfacing EEPROM with MCU using cable you need to conform on capacitance.

You can use an oscilloscope to check if their are any distortion in waveform. You can use a LCR meter to check the capacitance.

Try reducing bus speed 25kHz to 50 kHz and check waveform. Try increasing the strength of pull resister.

The problem with the wrong VCC capacity (4.2v instead of 5v for example) is, that the timing can be different to. (not fully verified, but it fixed the problem)

Mathlight
  • 6,436
  • 17
  • 62
  • 107
Dark Sorrow
  • 1,681
  • 14
  • 37
  • After I said that changing the wires worked, I tested it some more, but it didn't work anymore. Changed to other wires, but that didn't work to. But now I've fixed it. The problem was the 5v coming from the STM32. It gave me only 4.2v instead of the 5v. That's why the timing was off. If you could add a part about checking the current to your answer, I will accept your answer. Although it didn't fix my problem, It certainly can for somebody else, and it triggerd me in thinking about this. – Mathlight Jan 04 '18 at 18:44
  • @Mathlight, As per the datasheet if Vcc is bellow 2.5V then you should use should have bus speed bellow 100 kHz. Theoretically 4.2V should not cause any problems but I2C bus is full of mysteries. Have you tried operating at lower speed as I suggested? – Dark Sorrow Jan 05 '18 at 04:23
  • @Mathlight, how did you fixed the problem? It would be helpful for everyone to know for future reference. – Dark Sorrow Jan 05 '18 at 04:24
  • Theoretically is shouldn't be a problem indeed. But my Vcc is coming from the Arduino right now, and the communication is much more stable. Still not perfect though, but it's getting there. If I find out why the stm is giving me that less instead of the 5v, I would explain here in details what went wrong – Mathlight Jan 05 '18 at 07:39
  • Will do in a couple of hours. I'm also interested in seeing if I could use an pin as Vcc (set output to high, maybe that gives the correct 5v) – Mathlight Jan 05 '18 at 08:45
  • Turns out that the STM gives such a low voltage, because it's laptop powered. If I power it by a phone charger, it gets closer to the 5v. So that could explain why I couldn't get the 5v. Will now try to communicate with the EEPROM with 3v, see how that goes – Mathlight Jan 05 '18 at 15:08
  • Thanks for the update. You can increase USB supply current from OS settings. Just post what happens. Also try with low communication speed. – Dark Sorrow Jan 05 '18 at 15:19
  • Alright, I've tested it with the Arduino 3v and the STM32 3v now. The Arduino 3v gave the same results as the Arduino 5v (worked most of the times, but not stable). But using the STM32's 3v fixed everything. I now have clear communications, no hickups or other weird things. Thank you very much for bearing with me on this ;-) Although I didn't test the comm speed, you helped me find the problem and answer (sort of rubber duck debugging :D ) Have a nice new year! – Mathlight Jan 05 '18 at 15:30