Kinetis MicrocontrollersのトピックRe: losing my mind over i2c interfacing to 24lc00 eeprom

losing my mind over i2c interfacing to 24lc00 eeprom

steve_fae — Thu, 14 Mar 2013 05:35:14 GMT

Using PE example, got communication between FRDM board and 24LC00 but can't seem to write a read accurately.

First I do a block write then block read using typical example for I2C component.

volatile bool DataReceivedFlg = FALSE;

volatile bool DataTransmittedFlg = FALSE;

uint8_t OutData[4] = {0x00U, 0x01U, 0x02U, 0x03U}; /* Initialization of output data buffer */

uint8_t InpData[16];

LDD_TError Error;

LDD_TDeviceData *MyI2CPtr;

First picture is writing of data to device, only two values the first being address zero, second data value of 1.

Second picture is writing of control word and address zero to device in prep of reading

Third picture is the read

Re: losing my mind over i2c interfacing to 24lc00 eeprom

KeshavaGN — Thu, 14 Mar 2013 07:02:25 GMT

Hi steve_fae ,

What problem you are facing?

You have written what you did.

But what error you are getting?

With regards,

Keshava G N

Re: losing my mind over i2c interfacing to 24lc00 eeprom

steve_fae — Thu, 14 Mar 2013 11:30:33 GMT

Sorry. As I was editing the message it locked up. Basically I only read 0xff back. I've changed the timing from 93Khz down to 73Khz or so as well but it didn't help.

Sent from Steve Cohen's blackberry

(818)261-1033

Re: losing my mind over i2c interfacing to 24lc00 eeprom

KeshavaGN — Thu, 14 Mar 2013 11:43:11 GMT

Ok.

0xFF is the default state (ie: 11111111 in binary) of a byte in EEPROM (or any other storage device).

If you have not written any data byte to that address (or write is not successful), then 0xFF is the correct data.

So first write some data to that address and try reading the same address.

(Or if you have already written something, make sure that it written data correctly.)

With regards,

Keshava G N

Re: losing my mind over i2c interfacing to 24lc00 eeprom

JimDon — Thu, 14 Mar 2013 13:13:08 GMT

This is how you must write to this device:

1. Send the device address (0xA0 on the line) byte with RD/WR = 0.

WARNING: IIRC PE left shifts the device address, so instead of 0xA0 you may need to set the address as 0x50 look at the code.

2, If nacked give up or go back to 1.

3. Send the "word" address only the lower 4 bits are used.

4. Send the data.

5. Send stop.

ACKNOWLEDGE POLLING

loop on sending 1. and getting a NACK.

http://ww1.microchip.com/downloads/en/DeviceDoc/21178H.pdf

Re: losing my mind over i2c interfacing to 24lc00 eeprom

steve_fae — Thu, 14 Mar 2013 18:27:13 GMT

Hey Jim, if you look at my attached scope shots its all there. I am getting the ACKs and I believe the s.w. creates the correct START and STOP sequences. But I am definitely missing something.

Re: losing my mind over i2c interfacing to 24lc00 eeprom

JimDon — Thu, 14 Mar 2013 18:31:53 GMT

Not seeing an attachment.

Re: losing my mind over i2c interfacing to 24lc00 eeprom

steve_fae — Thu, 14 Mar 2013 18:38:20 GMT

Jim, you must view my original message under activity vs. inbox. Viewing it in the inbox view, you don't see any attachments. That was driving me crazy when I first started using this community.

Re: losing my mind over i2c interfacing to 24lc00 eeprom

JimDon — Thu, 14 Mar 2013 19:34:04 GMT

Oh, I see - well I see you write the control byte and address but I don't see a read on the scope.

The read should send the control byte (as a read) the read a byte, so you should really see 4 bytes transferred.

Re: losing my mind over i2c interfacing to 24lc00 eeprom

steve_fae — Thu, 14 Mar 2013 19:51:35 GMT

The last picture should show the read.

Sent from Steve Cohen's blackberry

(818)261-1033

Re: losing my mind over i2c interfacing to 24lc00 eeprom

JimDon — Thu, 14 Mar 2013 20:37:43 GMT

I did not see the third trace.

I think that on the final read, you should test for an error. You should get a NACK because the eeprom should be still writing. It looks like you get an ACK, but still you do need to test for NACK after writing and attempting to read.

Just retry the read until error comes back 0 (or get the error code when the done flag is set, not sure how PE handles this). Look on page 9 of the PDF link I posted.

According to that a write can take 4ms.

Also, make Avnet get one of these: Saleae Logic. .

Re: losing my mind over i2c interfacing to 24lc00 eeprom

steve_fae — Fri, 15 Mar 2013 00:50:44 GMT

The third trace was on the second page of the PPT file.

Re: losing my mind over i2c interfacing to 24lc00 eeprom

JimDon — Fri, 15 Mar 2013 02:07:25 GMT

Yes, I did see it.

As I said, even if this is not your problem, the code is logically incorrect. After the write you MUST check for NACK as this is what indicates the device is still writing. You then need to resend the address write. EEPROMs are relatively slow. I have "talked" to EEPROM on I2C many times and I assure this must be done.

Please read the pdf as I suggested, if you have not done so, it will make this clear.

Why do you init the I2C again?

Here is what I see as wrong - after the second write I don't see a stop. I also do not understand why the second write is acked, it should be nacked.

From the PDF:

"Since the device will not acknowledge during a write

cycle, this can be used to determine when the cycle is

complete (this feature can be used to maximize bus

throughput). Once the Stop condition for a Write

command has been issued from the master, the device

initiates the internally timed write cycle. ACK polling

can be initiated immediately. This involves the master

sending a Start condition followed by the control byte

for a Write command (R/W = 0). If the device is still

busy with the write cycle, then no ACK will be returned.

If no ACK is returned, then the Start bit and control byte

must be re-sent. If the cycle is complete, then the

device will return the ACK and the master can then

proceed with the next Read or Write command. See

Figure 7-1 for flow diagram."

Also I recommend that you not use power point to upload as some users do not have it. If needs be, paste the images together in paint, or save as a pdf.

Re: losing my mind over i2c interfacing to 24lc00 eeprom

steve_fae — Fri, 15 Mar 2013 03:03:33 GMT

Thanks Jim for your help. I am just not used to Kinetis yet.

I am trying the higher level component since it breaks it down more then the LDD. And in the typical example they actually provide typical usage for an eeprom. The only problem is I didn't know where to enable Cpu_Delay100US(100); which they use in between the write and then read of the eeprom.

here is my write

TransmitComplete = 0;

err = I2C2_SelectSlave(0x50);

buffer[0] = 0; //storage address

buffer[1] = 0x10; //data

err = I2C2_SendBlock(buffer, 2, &sent); //send storage address and data to the EEPROM

while(!TransmitComplete){} //wait for communication completition, this flag set in interrupt routine

err = I2C2_SendStop(); //Send STOP condition

send command 0x50, address 0, data 0x10 then send stop. Page 7 of Microchip AN974

for read I stopped the processor then trigger scope again since I didn't feel like putzing around with s.w. delay.

buffer[0] = 0;

err = I2C2_SendBlock(buffer, 1, &sent);

while(!TransmitComplete){}

err = I2C2_RecvChar(&data);

send command with WRITE, address withWRITE, then read but that doesn't follow the data sheet!!!!!

after control byte sent with WRITE, then address with WRITE, need to generate START with control again and READ, then data is read correctly.

so I need to figure out how to do this with the component methods available.

Re: losing my mind over i2c interfacing to 24lc00 eeprom

steve_fae — Fri, 15 Mar 2013 03:53:03 GMT

So before crashing I tried this code instead to generate a restart during the read.

But the restart in the middle of the READ process isn't a real START. The control word with WRITE and address with WRITE goes out fine. But err = I2C2_SelectSlave(0x51); creates a mess. Its not a valid start. I saw a message saying using the freq divider for the i2c clock can cause problems during a restart. Maybe there is an errata of some sort.

Re: losing my mind over i2c interfacing to 24lc00 eeprom

JimDon — Fri, 15 Mar 2013 13:38:05 GMT

Send I2C2_SelectSlave(0x51); is way wrong. If you look at the code, it shifts it left then sets the R/W bit (if it is a read).

When you set 0x50, it actually goes out as 0xA0. Not sure where the idea to left shift the set slave address comes from but PE is not the only one to do it.

Here is the article on the silicon error, don't know if it applies to your case:

KL25Z and I2C: Missing Repeated Start Condition | MCU on Eclipse

Re: losing my mind over i2c interfacing to 24lc00 eeprom

steve_fae — Fri, 15 Mar 2013 16:23:39 GMT

OMFG, I think the bug is exactly what I have been chasing. I had to remind my old brain about I2C which took a few days, but last night it was obvious that I am experiencing the same disease.

Laughing out loud, here is my current settings

Re: losing my mind over i2c interfacing to 24lc00 eeprom

steve_fae — Fri, 15 Mar 2013 17:39:10 GMT

Yeah I see now how 0x51 couldn't work. Got to find which PE command does a start condition + READ.

	}
	DeviceDataPrv->SlaveAddr = (uint8_t)((uint8_t)Addr << 0x01U); /* Set slave address */
	DeviceDataPrv->SerFlag &= (uint8_t)~(GENERAL_CALL \| ADDR_10); /* Clear the general call flag and 10-bit address mode flag */
	DeviceDataPrv->SerFlag \|= ADDR_7; /* Set 7-bit address mode flag */

Re: losing my mind over i2c interfacing to 24lc00 eeprom

JimDon — Fri, 15 Mar 2013 17:44:07 GMT

You should look at the PE code, I am pretty sure all that should be done there.

Also, now that you have fixed the repeated start condition, go back to what you had.

Re: losing my mind over i2c interfacing to 24lc00 eeprom

steve_fae — Fri, 15 Mar 2013 18:52:45 GMT

Unless I am cheating, I think it works now. I just informed my two customers who are about to do the same thing what the work around it. Thanks Jim. Now need to see what PE provides for timer delays for Kinetis like 100usec delays.