ERROR READ WITH AT24C32

[Alkaline]

Hello guys

I have a problem with the read macro of the serial eeprom component 24c32.
I am using an at24c32 microchip chip in a 5 pin sot23 package.
As from the "write" pdf the writing is performed correctly at the specified address, write 0x04 to the address 0xA0. When I go to read the address 0xA0 the macro reads correctly the value at the address A0 but does not receive the stop by the master.
Reading the datasheet of the chip, upon receiving the no ack, at the end of the random read of a single byte, the master must send the stop to the eeprom. This does not happen as can be seen in the document "read."
I also tried using i2c hardaware but it does not work by returning a completely wrong address.

I'm using a pic32mx470f512h

Thanks in advance

[Benj]

Hello,

In your project file please can you click on Help -> Check for updates and make sure everything is up to date.

If everything is up to date then tick the "Show up to date files" checkbox

Find the serial_eeprom component and try changing the new revision from 6 to 5.

Click Download, then OK and restart Flowcode.

Try compiling with the v5 component and let us know if this makes any difference, v6 of the component deals with allowing other I2C devices to control the bus and so this may have caused a bug on PIC32 devices.

[Alkaline]

Hi Benj

I tried to do as you suggested but it doesn't work.

I noticed through logic analyzer that the clock is correct (100khz) up to "setup read" and then increases up to 125Khz.( RED)

I also tried to perform a read through the blocks of the "i2c master" but also in this case I have the same result.

[Benj]

Hello,

If you add a delay between the Read and the Write then does this help at all? I've looked in the PIC32 CAL I2C code and it looks like we are waiting for events to happen e.g. the stop but maybe this is being skipped if the start is called again in quick succession.

Maybe also try the software channel and see if this helps at all? This will confirm if it's a component problem or a CAL problem.

[Alkaline]

Hi benj

I tried to do what you asked but unfortunately did not solve.

I confirm that I am using the i2c software mode.

I am attaching the program with the personal cal eeprom.

I tried to move the delay before and after the rest but nothing changes.

It almost seems like he's trying to do a sequential and not a single read.I can confirm that the value of the data read is correct so the writing is done correctly

[LeighM]

Could you add a short delay at the end of read_eeprom(), after Master:Stop
I don't understand where the extra clock cycles are coming from

[Alkaline]

I already tried this combination

I also tried inserting a ReceiveByteTransaction but without success.

The problem, in my opinion, is that when the master receives the NACK, he must stop the clock.

[LeighM]

when the master receives the NACK, he must stop the clock

Yes, that is true, although it is the master that sends the NACK when reading.
In software mode the CAL code generates the clock.
It generates one for the Stop, so why does the clock continue to run after that?
I thought if you added a delay and took another scope trace it might help us deduce where the clock is coming from.
I presume you have nothing else connected to this I2C bus?

[LeighM]

Just as a bit of a long shot, could you try dropping the attached file into
C:\ProgramData\MatrixTSL\FlowcodeV8\CAL\PIC32BIT

[Alkaline]

I replaced the file with the new one but nothing.

I'm using a mikro6lowpan demoboard.

The memory chip on the demoboard has been physically removed as photos.

doing further testing we think the problem is in the receive byte macro.

From the analysis of the logical states we assume that the ReceiveByte macro is not terminated correctly, it seems that the Nak is correctly sent by the MCU but in our opinion this does not happen .We think that the slave releases the bus, the logic analyzer interprets it as nak while the mcu is lost in some routine.
In fact the stop command not appear after the nak

[LeighM]

Hi,
Thanks for the trials.

We think that the slave releases the bus, the logic analyzer interprets it as nak while the mcu is lost in some routine.
In fact the stop command not appear after the nak

Yes, I agree.
From your pdf the only conclusion I can come to so far is that the code in Master:RecieveByte is continuously looping creating the clock output.
Can I just check, did you put the CAL file into C:\ProgramData\MatrixTSL\FlowcodeV8\CAL\PIC32BIT and re-compile?
(ProgramData is normally hidden by Windows)
Did you put a delay at the end of eeprom_read?
Although I don't think it's getting that far, but the delay was intended to prove that.
Thanks
Leigh

[Alkaline]

Hi LeighM

I put the file in the wrong path, now it works.

I tried both the manual and the 24c32 component read routine and both work.

Thanks again for the support

[LeighM]

That's good to hear, thanks!

[Alkaline]

I have one last question to ask you!

now at startup flowocde asks me to update the file that I replaced.

Can I replace it or not?

[LeighM]

Hi,
Sorry, not yet, the system still has the old version.
I'll ask Ben to push the new one
Leigh

Edit: You will be OK to download when the "New Revision" changes from 2 to 3

[Benj]

Hello,

Sorry for the delay the update should be available now.