I2C Addressing eeprom

retepsnikrep

Senior Member
I've a simple circuit with a picaxe 28x1 talking to a AT24C512B 512k bit 64k byte eeprom.

I'm happy with the circuit and the setup command.

But addressing the 64kbyte eeprom memory, is it as simple as incrementing the address pointer (0 in the below example) and reading/writing the data.

Code here

Code:
`Set PICAXE as I2C master and AT24C512B 512k bit 64k byte eeprom as slave

	hi2csetup i2cmaster, %10100000, i2cfast_8, i2cword	;Setup I2C Device 

`	hi2cout 0,(b0)					;write data to I2C Device starting at address 0
`	hi2cin 0,(b0)					;read data from I2C Device starting at address 0
I appreciate this takes upto 5ms per write and that multiple writes can be combined in one instruction.

lets assume I have a loop writing data and incrementing my pointer. Can this simply keep incrementing from 0-65335?

Can I then jump in at any time with a read command to access the data in a random fashion (changing pointer)

Thanks
 
Last edited:

westaust55

Moderator
when writing single bytes of data, then yes you can write the address at any point at random as you propose.

However the EEPROM has a 128-byte Page Write mode.

With page writing, you can send from 2 to 128 bytes of data in one write command. But you need to make sure that the data within one such write command does not attempt to cross a page boundary.

From the datasheet:
"The data word address lower 7 bits are internally incremented following the receipt of each data word. The higher data word address bits are not incremented, retaining the memory page row location. When the word address, internally generated, reaches the page boundary, the following byte is placed at the beginning of the same page. "
 

retepsnikrep

Senior Member
Well I now have my eeprom and inserted the code into my large program and it keeps crashing (resetting the picaxe).

This is my initialisation code. The address and write enable eeprom pins are all tied to ground. It's a 28X1 chip running at 8mhz.

Code:
symbol I2CAddress   =   w4 	;w4  Global (b8,b9)   = I2CAddress byte (0-65535) address of data byte to be written

`Set PICAXE as I2C master and AT24C512B 512k bit 64k byte eeprom as slave
`Note recording of data to eeprom starts at I2CAddress (0) each time BMS program is started

hi2csetup i2cmaster, %10100000, i2cfast_8, i2cword	;Setup I2C Device
Then I have the following commands sprinkled around the program to send the data I want to the eeprom.

Code:
hi2cout I2CAddress,(VoltageData)	;write VoltageData to I2C Device starting at I2CAddress
	
inc I2CAddress				;Increment I2CAddress word variable
Any ideas. The crashes are quite random and do not occur with the I2C stuff commented out. Sometimes the program will only run for a few seconds before resetting and other times it may run for a minute before falling over. The I2C routine is called about 50 times a second to write or read data.
 
Last edited:

lbenson

Senior Member
Can you simulate it or modify it so that it can be simulated? That would reveal stack errors--most likely unbalanced call/return.
 

hippy

Ex-Staff (retired)
As you noted, there is a time taken to write data to an I2C Eeprom. If the program doesn't include sufficient write time pauses then subsequent writes and reads may fail or return invalid data.
 

westaust55

Moderator
For the EEPROm you have, the write cycle time (Twr) = 10ms with 400kHz or faster i2c comms speed and Vcc greater then 2.7V.
If you have around 50 hi2c writes per second that is an average of 20ms between each but if those i2c writes are “sprinkled through the PICAXE code then there may be timing clashes.

Notwithstanding the above, the PICAXE will generally work and use i2c comms even with an i2c device missing – that is why sometime folks report reading 255 as return values, so there may be other issues.
It might be worth posting your circuit or at least looking at your wiring yourself.

  • ]Do you have decoupling capacitors across the Chip power supply pins (as close as possible)?
    Is there any electrical noise that could be getting into the i2c comms wiring?[/LIST
 

retepsnikrep

Senior Member
Thanks for the ideas, i thought about stack errors but the I2C stuff was inserted into subroutines which already existed and work fine without the I2C stuff. Good point about it working without a chip. I think it did work OK without the chip, I'll take it out and have a look. I have a decoupling cap next to chip and 4k7 r on the clock data lines. I suspect timing might be an issue. Too many writes in too short a time. Hmm
 

MartinM57

Moderator
If you can't easily sort the problem, consider using external FRAM rather than EEPROM. FRAM has, essentially, zero write time.

Search the forum for more info...
 

hippy

Ex-Staff (retired)
I'd recommend against changing technology simply to side-step a particular issue unless one knows exactly what the issue is and that this it is a known solution. Otherwise it may not solve the problem, and may simply make crashes less frequent, harder to track down, and in practice that is often more annoying than it was before.

If the program is crashing and resetting then it is best to track down where and determine why. Use of SERTXD to trace program flow can help there but addition of those can extend execution times and obscure timing bugs. To trap a reset-crash, but not when the program is first downloaded so a program can be left to run until it crashes without losing the trace leading up to that, I'd use a flag in internal Data Eeprom and add the following code to the start of the program -

Eeprom 0,(0)
Read 0, b0
If b0 <> 0 Then
SerTxd( "Crashed" )
End
End If
Write 0, 1
 

MartinM57

Moderator
I completely agree - I guess I wasn't clear enough....if your fundamental requirement is such that you can't live with the 10mS write time (e.g. I must datalog stuff to EEPROM every 2mS) then consider an alternative technology, whether that be a different EEPROM with faster write time or FRAM. And you get what you pay for - zero write time FRAM costs $$$

If you can fundamntally live with the 10mS write time, then you just need to identify the problem and sort it ;)
 
Top