24LC256 will not accept 32 bit data ending in "1"

R Pankau

This is all very strange and I need a fresh set of eyes to look at this.· I'm trying to write 32bit words to another 24LC256 mem chip on pins 26 and 27 to log accelerometer values.· The read and write driver is asm, (my first venture into asm) and it almost works!

If I write 4 consecutive bytes and retrieve them, the data comes back in-tack if the 32 bit value was even.· it does not matter where on the memory I put the data it rejects the whole 4 bytes if the last bit is a one.·· The mem chip is sending good acks after each byte sent but then when I go look nothing was written.· If an even value is written to the same address then it goes in presumably because it certainly comes back.··· The data sheet for the memory states that the clock needs to be high for 600 nSecs and low for 1300nSecs which I was not doing so I thought the problem was solved but it is slowed down now and still the same issue.·

I'd be glad to post the asm for this if anyone is interested.··

thanks.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Skogsgurra

My pair of fresh eyes would have a thorough look at the data, clock and control signal(s) again. It sounds like you leave something in an unexpected state when your last data bit is high. Do a pencil-and-paper simulation of what really happens during those last instructions.

Or, better yet, use the PASD (see that thread) by Ariba. It is exactly what you need for this kind of problems.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

R Pankau

Thanks for the tip about PASD, and thanks to ARIBA for sure!· I will try it.· It appears to have been a major task to undertake.··

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Phil Pilgrim (PhiPi)

In what order are you writing the 32 bits of data (bit order and byte order)?

-Phil

R Pankau

Most sig byte first and Most sig bit first. I'm just shifting the long to the left into C, 8 bits at a time and doing that 4 times.
Then for reading, everything is shifted into the LSB of a long (8 bits) * 4

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

deSilva

R.Pankau - it should be clear to you that our guessing here without your code is not very efficient. We can ask:" Is ist black? Does it lay on the table?" And you answer "Yes, No".
We can also give you general hints as to debug techniques (pencil-and-paper, "ViewPort", which might be of good help,...)

But it seems obvious that you have a bug in your code, and so not posting it, will hinder progress..

Post Edited (deSilva) : 9/15/2007 7:40:25 AM GMT

Phil Pilgrim (PhiPi)

My guess is that if the last bit written is a one (odd number), SDA returns high after the ACK, before SCL goes high. That makes it impossible to generate a low-to-high edge on SDA with SCL high. This means you're not generating a STOP condition, and the wrtie never takes place. If the number is even (last bit = 0), SDA is staying low, and you're able to generate the STOP. What you need to do is hold SDA low, once you've received the ACK, before raising SCL, then tristate SDA to let it pull high and generate the STOP.

Remember outa[noparse][[/noparse]SDA] := 0, always. dira[noparse][[/noparse]SDA] is used to control the state of the SDA pin: dira[noparse][[/noparse]SDA] := 1 => SDA is low; dira[noparse][[/noparse]SDA] := 0 => SDA is high.

-Phil

deSilva

Good guess!

Fred Hawkins

R Pankau said...


I'd be glad to post the asm for this if anyone is interested.··

Please post it. Code is always welcome here.

Andy Lindsay (Parallax)

Hi,

Here's a Propeller Eeprom object I'm preparing for the next Propeller Education Kit lab.· It's written in Spin and has been working pretty well so far.· It might help for comparison's sake.· Also, if you unearth any bugs in it during the comarisons, please let me know.

Thanks, Andy

P.S. Hoping to post demo code to another thread later this weekend.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

R Pankau

Thanks for all the "guessing" I will post the code as soon as I get out from under these 3 kids and down to my computer.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

R Pankau

Ok, I'm back briefly.·
Phil, if I follow you, your saying that after the last byte is transmitted the SDA line is left in its last state, then when the Stop is issued there is no transition for SDA if it was already a 1.

Look at line 243 snd_data, here is where I'm sending a byte out, then look at line 305 stop, I have totally left SDA flapping in the wind and I think you nailed it Phil.·· I have not tested it yet but it looks like this must be it.· GOOD DIAGNOSTICATING!· Thanks!.··

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

R Pankau

Just to confirm, it does work. I added andn for the SCL and SDA pin in the beginning of the stop routine.

Thanks again!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Phil Pilgrim (PhiPi)

I'm glad it works. But one thing I notice in your code is that you're driving SDA high (e.g. or outa,SDA_mask). All transistions on SDA should be done via dira, allowing the pullup to pull the pin high. The SDA bit in outa should always be zero.

-Phil

deSilva

This is something most likely to be repeated over and over again for OC circuits..

R Pankau

That seems counter-intuititive, about sending the data via the dira reg instead of the outa reg.· Is that mainly due to the need to have the data line in a high impedance state for 1s???·· I guess another device on the bus could then pull the data line low.··

Is there more to it than just releasing the bus or would you say that electrically it is a better practice to allow the pullup to create the high state?·· I would think that the master would only incur electrical current for low periods even if using outa.··



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Peter Jakacki

All single master I2C I have ever done has always actively driven the clock and data line. If you are going to implement multi-master then it is necessary to drive both the scl and sda as open-drain but that is only the start of the story.


*Peter*

Phil Pilgrim (PhiPi)

Peter,

I beg to disagree. Even in single-master I²C systems, neither master nor slave devices should ever drive SDA high, since it's bi-directional. The whole idea is to avoid bus conflicts. Moreover, it's okay for a master to drive SCL high only when the slave devices are incapable of clock stretching. In most cases, that's a safe bet, but you do have to read the datasheets to make sure.

-Phil

R Pankau

Phil, you say that because it is bidirectional that no-one should drive the data line directly.· Is that an I²C standard?· Seems like one could set the rules of a protocol such that everyone knew when to receive and when to transmit.· I don't know I²C well enough to guess.··

Although...... I guess there could be some nasty currents on the line and through devices if One was driving low and the other high, then the current would not go through any resistor and could burn either device.· This would effectively be a short.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Phil Pilgrim (PhiPi)

Yes, that's an I²C standard. This, from the I²C-bus Specification, Version 2.1 (NXP Semiconductors, January 2000), p. 8:

····"The output stages of devices connected to the bus must have an open-drain or open-collector to perform the wired-AND function."

In most single-master systems, though, SCL can be driven both high and low, since it's not bidirectional. The exception occurs when there are one or more slave devices on the bus that employ clock-stretching to slow the timing. In that case, the same rules apply as for the SDA line.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 9/16/2007 5:16:00 AM GMT