i2c problem

#1
Hi folks,
I am about to load some data into a FRAM chip. so I decided to re-familiarise myself with i2c stuff.
So, I made a small program to load a character into an Eeprom at location 00 and then read it back.
It is a new Eeprom, so I expected the contents to all be $FF to start with.
I ran the program and the debug showed that it had read $FF - there were no signs of a write having happened!
Then I ran another program to control a new RTC chip (DS1307).
Indications are similar - there are read results of $FF but no sign of a write happening.
This is my first attempt to use the new Hi2c commands - have I missed something?
I am using a Picaxe14M2 and it programs OK.
I had a quick look on both SDA/SCL lines with a DSO, and the pulses seem to be present.
I tried another Eeprom (a used one) with same result - no change to the read data.

Here is the code used for the Eeprom:
Code:
    hi2csetup i2cmaster, %10100000, i2cslow, i2cbyte
write_data:
    
    pause 500
    hi2cout 0, ("X")
    pause 1000
    
read_data:
    hi2cin 0, (b0)
    pause 100
    debug b0
I have double checked all connections and they OK.
The WP pin on the Eeprom is set to 0V (pin 1).
Originally I ran the program from a V5 editor, then swapped over to the V6 on another PC - same result.
Comments?

kenmac
 

Aries

New Member
#2
I assume you have got the 4.7k pull-up resistors in place and that the pins on the eeprom match the address.
(1) If nothing has been written to the eeprom, I would expect 0, not $FF, to come back.
(2) How many addresses does your eeprom have? You have used i2cbyte as the addressing mode, meaning a maximum of 256 addresses. Your eeprom is almost certainly expecting a word address, so your "X" is being interpreted as the second part of the address, with no data to read or write thereafter.
 

AllyCat

Senior Member
#3
Hi,

My data sheet for the DS1307 gives a slave address of %11010000 not %1010.... ? When testing I2C, it's always worth reading back a "known" value, ideally the "Identity" register (if it has one), but at least something with an expected number of 0s, to check that the slave address is correct.

Cheers, Alan.
 
#4
Aries,
I'm using a 24LC256 Eeprom.
It will have all memory bytes as $FF when new (never programmed).
It should work OK with bytes.

kenmac
 
#5
Allycat,
It's OK - I only showed the code for the Eeprom.
I used the correct address for the RTC.
With a new chip, the registers will always hold $FF.
The fact that doesn't change when the program runs means the write has failed!

kenmac
 

Aries

New Member
#6
Aries,
I'm using a 24LC256 Eeprom.
It should work OK with bytes.
kenmac
The 24LC256 holds 256Kbit (=32k bytes), so it has an address length of 15 bits, hence it needs word addressing (if you look in Hippy's python code for the FRAM conversion, you will see which eeproms need which type of addressing).

From the datasheet:
The next two bytes received define the address of the first data byte (Figure 5-2). Because only A14...A0 are used, the upper address bits are a “don’t care.” The upper address bits are transferred first, followed by the less significant bits.
I2C on Picaxe returns $FF when the I2C fails. You cannot assume that it has worked and returned $FF.
 

hippy

Technical Support
Staff member
#7
The 24LC256 holds 256Kbit (=32k bytes), so it has an address length of 15 bits, hence it needs word addressing
I would also suggest it is using I2CBYTE rather than I2CWORD which is the problem.

Note that is a specifier for the size of address rather than size of data.
 
#8
Hippy,
Thanks, you are correct of course.
I went back to the Manual again and found that it requires i2cword!
I shall correct that tomorrow and hopefully we can proceed.

kenmac
 
Top