I2C Stop condition issue with MikroBasic library

[iQd]

Hi,

I have been making functions for reading and writing 24AA1025 1Mbit EEPROM chip.
I use PIC32MZ2048EFH144.
I noticed that while I can read it ok, writing does not work at all.

I diagnosed this for some time until I noticed that the MikroBasic I2C implementation of the Stop condition function is wrong, which causes the EEPROM to never actually start the write cycle.
The Stop condition should be clear movements of the SDA and SCL lines, now what I see is just a small 'glitch' that has no timing.

Some components seem not to care about this, as I can read and write an RTC chip just fine with the same library.

This is the code that I used for writing before I found what the problem was:
I2C1_Start()
I2C1_Write(Control_Write) ' Send command for selecting address write mode and block.
I2C1_Write(hi(EEPROM_Write_Byte_AddressWord)) ' Address to be written to, high byte.
I2C1_Write(lo(EEPROM_Write_Byte_AddressWord)) ' Address to be written to, low byte.
I2C1_Write(WriteByte) ' Byte to be written.
I2C1_Stop()

This does NOT perform the write cycle and nothing happens with the EEPROM.

When I ask the processor itself to create a Stop condition via I2CxCON register, it works fine and I can see from the oscilloscope that it is by far better looking than the little 'glitch' that the library makes.
So, by replacing the last line of the code with:

I2C1CON.PEN = 1

...I get a normal write and it functions perfectly.

MikroE, nobody noticed this when you guys were making the library?
I mean, if you look at it with the oscilloscope, you can clearly see that the Stop condition cannot be right, it jumps right at you.

I don't like losing time over things like this. Something like this should be tested and working already, as the product is not new.

Thanks.

[stefan.filipovic]

Hi,

I apologize for the inconvenience caused by this.

I believe the library is written for revision A1 of PIC32MZ MCU. According to the Errata sheet, there were some issues related to Stop bit. The workaround was restarting the I2C module via ON bit (I2CxCON<15>).
https://ww1.microchip.com/downloads/en/ ... 00663L.pdf
You can read more about it in the following topics:
https://www.microchip.com/forums/m1103301.aspx
https://www.microchip.com/forums/m1107929.aspx

I'll forward this to our developers for inspection.

Kind regards,