18m2 I2c

Hello again

having troubles with I2C.....


YES 4k7 PULLUP resistors are in place on the I2C lines SCL and SDA.

I am using the 24LC256 EEPROM from Techsupplies.

I had it working on a 20X2 a while ago, but took me several hours to get working.

Now I have spent several hours trying to get this working on brand new 18M2s but no luck. Have had the 18M2 working in the breadboad for a week and have tried a second 18M2 and same problem, so rules out the chip.

Running on 4v (3x AA Batteries) which is both inside the 18M2 and the EEPROMs voltage ratings.

All EEPROM addresses are held low and the WP is also held low.

code below:

The sertxd (and tried with a debug) both bring up the variable value of 255.

I am probably missing some stupid fundamental... Can any body spot anything wrong here?

Do you have the three address pins on the 24LC256 all pulled down to 0V ?

Photo time ?


EDIT:
Are you using the 18M2 on the AXE181 touch sensor demo board. If so, the resistor and LED on pin B.4 will affect the i2c bus clock and you will likely only see values of 255

all pins along the left hand side of the chip are pulled down to common ground.

edit:

even though it doesnt look like it is, the wire is connected to phys pin 5 on the EEPROM

http://picasaweb.google.com/liambealester/PhantomUAV#5510350862612253778

westy, I just have it on a breadboard. no touch sensors or peripherals attached.

FYI just put it back into the 20X2 and it is working

Hi Elios,

The program simulates okay but I can confirm that I also cannot get the program to save data into and EEPROM and read it back.

I have tried the HI2CSETUP with HI2CIN and HI2COUT
also tried the i2cslave with i2cread and i2cwrite.

have tied with I2CFAST and I2CSLOW as well.
.

Always the same results.

Tried with an 18X and works with the i2cslave with i2cread and i2cwrite.

Tried a different 24LC256 just in case and the 18M2 cannot work with either but the 18X works with both.

Well thats a big let down.

These chips were critical to my project with their multi threading

I have now even tried the 18M2 chip in my 18X weather station project where the 24LC256, pulll-up resistors, wiring, etc are all well and truly tested.

wrt i2c comms to/from EEPROM - - - Nothing!

Lets wait and see what hippy or others have to say . . . .

westaust55 said:

Hi Elios,

The program simulates okay but I can confirm that I also cannot get the program to save data into and EEPROM and read it back.

I have tried the HI2CSETUP with HI2CIN and HI2COUT
also tried the i2cslave with i2cread and i2cwrite.

Click to expand...

Just a thought. Can you read the 24LC256 when it has been written to by another PICAXE eg 20x2? Or does it just get $FFs?

Hi IWP, already tried writing with the 18M2 and then disabling the line that writes to the EEPROM, so as to see if with the 18X could see whether the 18M2 had written anything.

No sign of any writing by the 18M2.


Just using a multimeter (and extending the string out to 14 bytes), there is sign of activity on the data and clock lines of the 18M2.

inglewoodpete said:

Just a thought. Can you read the 24LC256 when it has been written to by another PICAXE eg 20x2? Or does it just get $FFs?

Click to expand...

nothing.

If its not over-writing then it should still read the previous data.

just $FF

edit: I hope they get replaced or a DIY update firmware as I am not re ordering 10 chips..

Try changing the pin settings with dirsb and adcsetup. I had a similar issue with the chip although not i2c which needed these setting explicity to work as I wanted

Best Regards

Peter

thanks for that insight matherp.

Reading about adcsetup suggests the digital and analog are both "connected on startup and the adcsetup really only disconnects the digital part of the input.

The hi2csetup is intended to "configure the PICAXE pins for i2c use and to define the type of i2c device to be addressed".
As such (by assumption) and the fact that the i2c data line has to be switched between output and input modes would have thought no other commands were necessary.

I will leave it to Elios to experiment further this evening . . . .

You can be assured that we did test I2C on the 18M2 with a variety of devices and it was working so we will have to investigate the issue further.

My 'Auto-Detect Eeprom Size' program which writes data to the Eeprom and then reads it back to see where that data is identifies a 24LC16 and 24LC512 correctly and other tests also appear to work.

HI2CSETUP I2CMASTER / I2CSLAVE / SLAVEI2C plus HI2CIN / I2CREAD / READI2C and HI2COUT / I2CWRITE / WRITEI2C, are synonyms of each other on the 18M2, provided to make it easier for those upgrading from 18X devices. We recommend using the HI2C commands but it doesn't really matter which are used.

I will need to run further tests but I have to go out so that will not be until later. I'll report back on the results.

elios said:

I hope they get replaced or a DIY update firmware as I am not re ordering 10 chips.

Click to expand...

There is no support for DIY firmware updates but we do offer a firmware update service. Depending on the outcome of tests we will be better able to offer advice on how to proceed.

As a side distraction, the original test code (post #1) should be more like:
should read (edit- whoops, slips, in this case it shouldn't):
Does it work any better if you use the slow mode i2cSlow?

Does the chip work with any other i2c slave device?

Can you (or anyone) see what's happening with an oscilloscope?

[mental note to self: "wait until rev 2 or 3 of the firmware before buying in big with a new model chip"]

inglewoodpete said:

As a side distraction, the original test code (post #1) should be more like:

Code:

sertxd ("",b0,b1,b2,b3,b4,CR,LF)

should read:

Code:

sertxd ("",#b0,#b1,#b2,#b3,#b4,CR,LF)

Click to expand...

Since the data to write to the EEPROM in post 1` was "Hello", SERTXD of the bytes displays those characters as "H", "e", "l", "l" and "o"
well it would if they were being written and saved - does in the Simulator

[qoute]
Does it work any better if you use the slow mode i2cSlow?
[/quote]
No, mentioned in post 6 that I had tried i2cslow as well.

Does the chip work with any other i2c slave device?

Click to expand...

I have some 24L16 chips which hippy has flagged as tested, so will try with those on Sunday if I get a chance between BBQ party activities.

It appears there is an issue which affects Word Addressed Eeprom which will require more investigation. Byte Addressed Eeprom and other I2C Devices ( such as DS1807 ) appear not to be affected.

A 'more immediate workround' would be to implement Word Addressed Eeprom access using bit-banged software. I will look at creating such routines for the 18M2 and publishing them here.

We apologise for the inconvenience.

Thanks hippy.

I can confirm that using a 24LC16 does work.

However with the program example suitably adjusted for the 24LC16 I spied that the SERTXD command output is frequently "missing the first 1 or 2 characters. I added a counter variable and can verify that when using the DEBUG line, that the first byte always changes on read back so not related to the i2c comms.
See the attached image for the code and SERTXD as received at the PC

If I use multiple SERTXD commands each outputting a space and just one of the bytes of data on each line, then the output of many of the SERTXD commands effectively does not get through to the PE (V5.3.1) terminal window.

@ westaust55 : Same program as above and I'm not seeing any dropped digits on my setup. Not sure what's going on. "Time for bed", said Zebedee

AXE091 dev board, 5.0V & 3.3V, 19.7C.

@hippy,

I can confirm that is NOT in fact related/specific to the 18M2 chip.

I have just tried the exact same program with my 40X1 which has never before exhibited dropping of characters and I am getting the same problem with the 40X1 sending data to the PE [F8] terminal window.


Hmmm, but then just ran on of my 1-Wire programs via the 40X1 and all text to the screen is perfect.
Then immediately re-ran the program on the 40X1 (adjusted back to word addressing to use a 24LC256 on my 40X1) and results in dropped characters at the PE terminal window.

Check that it is a space in the quotes and also that it's not double-quote-double-quote. It may be a non-printable character messing up the Terminal display. Perhaps delete and re-type the SERTXD.

Thanks hippy.
spot on.

retyped the SERTXD line and all is well.

Must be too much partying with family, workmates, friends last few days

Word Addressed.. Hopefully that does not include the SD21

Take Care
Dave

The AXE031 (SD21) is byte addressed so should work.

re:

Hi,
I dont know if its relevant, but i read in the help file something about using the _8 for 8mhz
etc...will give it a try
regards john

Shouldn't be any need to use _8 anywhere as the 18M2 is being run at default speed which is 4MHz. Of course it depends on whatever it is we're talking about ;-)

Hi
Sorry Hippy,
I was reading the section on the M2, and there is reference to using ICfast_8 etc. I just thought it may be due to frequencies used.

regards john

Note to self, read the forum more often.....

I would not have spent most of today tearing my hair out as to why I could not get this 18m2 to talk to this 24lc512...........

Oh well

Ridley

re:

@hippy

Please could you let me know which manufacturer the 24lc512 that you got working with the 18m2
thanks & regards John

At present it appears that the 18M2 has problems with all word addressed Eeproms regardless of manufacturer.

idea: is it possible to have a slave 20x2 (or similar) which can then look-up and write data to and from the EEPROM?

like a storage computer?

I have no clue how that would work though

If you could establish an inter-master protocol in code so that each master would hand off control to another and reconfigure itself as a slave, then yes.

Alternatively, it may be possible to carefully use (something like) a CD4066 switching to keep the 2 masters from causing collisions on the i2c bus.

@ elios : Yes, that should work ...

20X2 configures itself as slave
18M2 configures itself as master
18M2 asks the 20X2 for some data
18M2 stops using the I2C bus
20X2 configures itself as master
20X2 accesses Eeprom
20X2 configures itself as slave
18M2 retrieves the data from the 20X2

The only question is how the 18M2 will behave when it's on the same bus when the 20X2 becomes master and accesses the Eeprom.

Electrically it should be safe if the 18M2 I2C Bus pins are not altered while waiting and until the 20X2 has returned to being a slave, it's more a question what the 18M2 I2C hardware does and how that affects its internal I2C states when the 20X2 communicates as master. I have no idea. A 4066 will disconnect the 18M2 from the bus so that woud be a solution.

The 18M2 I2C issues will be resolved so it's possibly not worth going to the trouble of implementing such a 20X2 interface ( though of interest in itself to see if it does work ), a better stop-gap is to implement bit-banged I2C on the 18M2. I have the code written and preliminarily tested and I'll post that shortly.

Thanks hippy. That's great.

Is is possible to be supplied a date when the new firmware revision comes out?

Just would like to be organised for when I need to sort out sending them back and getting it updated.

Thanks

[edit] Couldn't you just low the ports the I2C is on? Wouldn't that disconnect it completely?

The issue is under investigation but we don't have a date for when new firmware will be released at this time. Obviously as soon as possible is what we are working towards.

Setting the I2C bus pins low won't work and it's even worse if you set them high - potentially catastrophic in a multi-master configuration. A PICAXE has to completely relinquish all control of the bus by setting its bus pins as inputs, which is effectively the state the PICAXE bus pins will be in when it's not accessing the bus.

The actual situation is that the PICAXE I2C pins are input with output via an open collector buffer, this is why the pull-ups are needed, and when the PICAXE isn't accessing the bus it leaves the bus to float high and be pulled down by other I2C masters and devices.

Set the pins low and no I2C device can let the bus float high, all I2C will fail. Set the pins high and any I2C device pulling the bus low will short the high output to 0V which is often the secret 'release the magic smoke' command.

With many thanks to Technical we appear to have a workround for the 18M2 Word Addressed Eeprom issue which doesn't involve jumping through too many hoops and should be relatively easy to change in existing source code.

Hopefully the example code will make things clear but if there are any specific commands anyone needs converting then we'll be pleased to help out.

Basically it works on the data on the I2C bus looking the same whether the bus is accessed in byte addressing mode or in word addressing mode, that is, using byte addressing mode to put on the bus what would be seen in word addressing mode. It sounds more complicated than it is to achieve.

There's a three step change process -

I2C Initialisation

Change "I2CSLAVE $A0, I2CSLOW, I2CWORD"
to "I2CSLAVE $A0, I2CSLOW, I2CBYTE"

Change "HI2CSETUP I2CMASTER, $A0, I2CSLOW, I2CWORD"
to "HI2CSETUP I2CMASTER, $A0, I2CSLOW, I2CBYTE"

Writing I2C Bytes

Change "I2CWRITE adr, ( dat1, dat2 ... datN )"
to "I2CWRITE adr.msb, ( adr.lsb, dat1, dat2 ... datN )"

Change "HI2COUT adr, ( dat1, dat2 ... datN )"
to "HI2COUT adr.msb, ( adr.lsb, dat1, dat2 ... datN )"

Reading I2C Bytes

Change "I2CREAD adr, ( dat1, dat2 ... datN )"
to "I2CWRITE adr.msb, ( adr.lsb ) : I2CREAD ( dat1, dat2 ... datN )"

Change "HI2CIN adr, ( dat1, dat2 ... datN )"
to "HI2COUT adr.msb, ( adr.lsb ) : HI2CIN ( dat1, dat2 ... datN )"

Example Code for 24LC512 etc

The following is a more comprehensive test. It writes different values to each of the first 512 bytes of Eeprom in one go, then reads each individual value back to check it is as expected. The values written change on each pass. Change the $01FF in both FOR-NEXT to test larger areas.

Note that it runs with I2CFAST_32 at 32MHz.

Don't forget to 'Clear Hardware Memory' or download some other code after testing or you'll have a program which hammers Eeprom when it next powers-up.

hippy said:

@ elios : Yes, that should work ...

20X2 configures itself as slave
18M2 configures itself as master
18M2 asks the 20X2 for some data
18M2 stops using the I2C bus
20X2 configures itself as master
20X2 accesses Eeprom
20X2 configures itself as slave
18M2 retrieves the data from the 20X2

The only question is how the 18M2 will behave when it's on the same bus when the 20X2 becomes master and accesses the Eeprom.

Electrically it should be safe if the 18M2 I2C Bus pins are not altered while waiting and until the 20X2 has returned to being a slave, it's more a question what the 18M2 I2C hardware does and how that affects its internal I2C states when the 20X2 communicates as master. I have no idea. A 4066 will disconnect the 18M2 from the bus so that woud be a solution.

The 18M2 I2C issues will be resolved so it's possibly not worth going to the trouble of implementing such a 20X2 interface ( though of interest in itself to see if it does work ), a better stop-gap is to implement bit-banged I2C on the 18M2. I have the code written and preliminarily tested and I'll post that shortly.

Click to expand...

hippy, I think there should be a couple of extra steps in that sequence so that the 18M2 knows when to take control of the bus again:

20X2 configures itself as slave
18M2 configures itself as master
18M2 asks the 20X2 for some data
18M2 stops using the I2C bus
18M2 configures itself as slave
20X2 configures itself as master
20X2 accesses Eeprom
20X2 Tells the 18M2 to take over
20X2 configures itself as slave
18M2 configures itself as master
18M2 retrieves the data from the 20X2

@elios: If either leg of the i2c bus holds low, the master restarts. Not a good way to keep the proposed system stable!

Peter

True, it helps if the 20X2 can signal the 18M2 when it's finished rather than the 18M2 just relying on a PAUSE. The 18M2 can't go into I2C Slave mode though as that's not supported. As long as the 18M2 doesn't try to use the bus while the 20X2 is master everything should be okay ( with earlier caveats ).

hippy said:

As long as the 18M2 doesn't try to use the bus while the 20X2 is master everything should be okay ( with earlier caveats ).

Click to expand...

Whoops, slips I'd overlooked that limitation of the 18M2. My main workhorses are the X1s and X2s.

Hi2c Scratchpad and 18M2

I'm about to venture into the Hi2c area with an 18M2, and have a question

Although the 18M2 does not have a scratchpat the same as the X2's, is it still possible to use an area of the 256 byte user area as a scratchpad.

I will be loading chunks of 50 bytes or so from an UaLFat and this will be far easier than doing individual byte reads

Many thanks for any advice

Dave