I2C EEPROM bit-golpes: Escribe bien, pero sólo si el primer bit está establecido en no

Question

Actualmente estoy trabajando en un I2C EEPROM del proyecto el uso de los bits de golpear a la unidad de la SDA y SCL líneas.

Mi función de lectura funciona bien, pero cuando escribo cualquier byte con un "1", siempre leo FF de vuelta, incluso si el byte ha sido programado con algo más antes. "0" es perfecto. No es mi lectura de rutina; como puedo ver en el ámbito devuelve FF.

Estoy buscando sugerencias sobre por qué esto podría ser. Es allí cualquier obvio que me podría pasar por alto que podría causar el problema? [No puedo publicar el código confidencial de la empresa... :(]

Cada forma de onda miro cumple con la especificación exactamente. Yo soy de desacoplamiento de la EEPROM. Mi pull ups son 2.2 k de modo que dentro de especificación. Me estoy registrando en alrededor de 500 Hz en este prototipo. El chip es el envío de Ack para cada uno de mis bytes por lo que los reconoce. Pero simplemente no funciona...

Estoy utilizando un Microchip 24LC256.

Simplificado algoritmo de escritura de un byte:

wait
SDA low
SCL low
wait
for each bit
    if bit is set:   SDA high
    if bit is unset: SDA low
    wait
    SCL high
    wait
    wait
    SCL low
    wait
wait
SDA high 
SCL high
wait
wait
check ACK status
SDA low
SCL low
wait
return ACK status

Simplificado algoritmo de lectura de un byte:

wait
SCL low
SDA high
for each bit (8 bits)
    SCL high
    wait
    wait
    SCL low
    wait
    check and store received bit
    wait
do a NACK or ACK depending on if it is the last byte

Answer 1

Usted está leyendo los datos después de reloj es baja de nuevo. Usted tendrá que hacer que entre hacer el reloj de alta y lo que es bajo. Después de que el reloj está bajo el esclavo es permitido cambiar la línea de datos, si bien no es alto.

Por lo que la lectura debe ser como este:

wait
SCL low
SDA high
for each bit (8 bits)
    SCL high                      <--------
    wait
    check and store received bit  <--------
    wait
    SCL low                       <--------
    wait
    wait
do a NACK or ACK depending on if it is the last byte

Answer 2

El problema al final resultó ser que estaba inadvertidamente el envío de una condición de PARADA, bajo ciertas condiciones, debido a alterados de temporización. Dejé de usar el alcance y salió de la lógica del analizador, y fue capaz de solucionar el problema en 15 minutos, ya que destacó la PARADA que no debería haber estado allí. Voy a elegir a quién dar la recompensa basado en la mayoría de responder de manera útil. Gracias por todas las soluciones.

Answer 3

Suena como que podría ser un par de cosas:

1. ¿Qué otra cosa es en el autobús? Podría haber una contención de bus con otro dispositivo, que se celebra en restablecer o no?
2. Son correctamente el cambio de la dirección de I/O pin? Si se está trabajando bien en la salida de caso, puede que se haya olvidado de cambiar la dirección de los pines de entrada y siempre leer 0xFF. El pin podría quedar como una conducción de salida del autobús mientras estás leer de ella.
3. ¿Tienes interna de pull-ups en el pin de la misma y/o en las líneas de e/S? Los microcontroladores suelen dar un rango de resistencia y no un valor fijo. Es posible que desee deshabilitar el pull-ups en el micro y usar sólo el discretas en el autobús como usted puede conseguir una más precisa de la resistencia pull-up a partir de componentes discretos.
4. Reloj de polaridad - ¿estás seguro de que se está midiendo en el borde derecho/fase entre el reloj/datos? Usted podría fichar a cabo lo que se ve bien en el ámbito de aplicación, pero si la fase está fuera de línea todos sus EEPROM se ve es 0xFFs (y sería más probable que devolver el mismo es probablemente un comando no válido/condición).

Answer 4

He presentado esto como un comentario anterior, pero mi confianza en que la respuesta ha sido el silencio que crece en los rincones más profundos de mi mente así que estoy promoviendo a una respuesta.

Tengo un loco corazonada de que esto es casi seguro que un bajo nivel de errores de software relacionadas con signedness de algunas variables. En su para cada uno de los bits de código, se le inadvertencia de inicio de sesión se extiende con un desplazamiento a la derecha de la operación? Si, a continuación, sus principales uno al final te dejan con una 0xFF después de las 7 de las operaciones del turno.

Steven se refirió a esto en un comentario, pero han sido testigos de la santidad de sus operaciones de escritura en un osilloscope, o ¿sólo suponer que el trabajo basado en la mitad de la lectura de espaldas mirando bien? Si usted no ha intentado buscar en la operación de escritura de el valor 0xAA, que podría ser una buena cosa para probar.

Si usted puede proporcionar el código de tu bucle interno y asociados declaraciones de variables que podría ser capaz de detectar un error.