¿Es seguro no alimentar este chip USB a I2C cuando el USB no está enchufado?

Estoy trabajando con alguien en un registrador de datos basado en un MSP430. Como funciona con batería, queremos que el dispositivo use la menor cantidad de energía posible. Estamos planeando usar este chip (FT201X) para conectar el dispositivo con USB en la próxima revisión. Cuando el chip está funcionando, consume una cantidad considerable de corriente, y cuando está en modo de espera, la corriente consumida (125 μA) sigue siendo mayor que la de varios otros componentes de la placa, por lo que parece que reduciría la duración de la batería de manera no trivial, lo cual no es No es deseable ya que el chip no hace nada cuando no está conectado al USB. La mayoría de las veces el dispositivo no estará conectado al USB. El dispositivo tiene su propio bus I2C conectado solo al MSP430, por lo que deshabilitar el bus podría funcionar, pero agregaría hardware para manejar los pull-ups.

Mi pregunta es si es seguro o no dejar el FT201X sin alimentación (es decir, solo alimentado por USB y sin alimentación por el circuito) para un uso normal y solo dejar que se encienda cuando el USB esté suministrando energía. Me preocupa que las líneas I2C, cada una de las cuales tendrá una resistencia pull-up de 1K a 3,3 V, puedan dañar el chip cuando no tenga energía. La hoja de datos dice que las entradas tienen una resistencia interna de 75K, pero el SDA podría ser el problema. ¿Tengo razón al suponer que esto es una mala idea?

Además, ¿qué otras opciones podría tener? ¿Es posible que pueda alimentar VCCIO pero no VCC? Esa podría ser mi opción favorita si es posible. Supongo que otras opciones incluyen conectar los pull-ups a FET o, supongo, alimentar el chip siempre. ¿Hay mejores formas?

Respuestas (2)

¿Por qué no simplemente hacer lo que sugiere la hoja de datos como ejemplo de aplicación para un convertidor de USB a I2C? ¿Cuál tiene el chip USB alimentado a través de USB y los pull-ups a través del VCCIO que es impulsado por los chips USB 3V3OUT? En ese caso, los pull-ups no estarían activos cuando el dispositivo USB no está alimentado y creo que no debería haber ningún problema...

Si hace esto, debe tener cuidado de no intentar acceder al bus I2C desde el maestro mientras los pull-ups no están encendidos. Vería una condición de bus ocupado que no se puede borrar y podría bloquearse si no se codifica correctamente.
Ni siquiera había pensado en eso, pero es la solución obvia. ¡Gracias por señalarlo! @DoxyLover, este bus I2C se dañará, por lo que probablemente configuraré SCA y SCL como entradas para indicar cuándo hay alimentación USB, pero tiene razón, eso es algo importante que debe buscar cuando el dispositivo se desconecta espontáneamente. Gracias.
En mi opinión, cualquier función que acceda al bus I2C siempre debe tener algún tipo de tiempo de espera para evitar situaciones en las que pueda entrar en un bucle infinito esperando que se borre el bus. También en este escenario, el maestro probablemente debería verificar que las señales sean altas antes de emitir una condición de inicio.

Descargo de responsabilidad: soy principalmente un principiante.

Por lo que he aprendido hasta ahora, el peligro de conducir las líneas de E/S más arriba que el suministro es que impulsa los diodos de la base del colector en los transistores en el búfer de entrada en dirección hacia adelante.

Si el riel de suministro está conectado a tierra, y suponiendo una caída de voltaje directo de 0,6 V, eso deja 2,7 V a través de 76 kΩ de resistencia, por lo que se filtrarán aproximadamente 36 µA allí.

Si no mantiene el riel de suministro conectado a tierra mientras el IC está apagado, entonces flotará a 2.7V, lo que puede causar un comportamiento muy interesante.

Creo que el enfoque de "mantener VCCIO alimentado" puede funcionar. Si ese chip no tuviera su propia lógica de búfer/controlador, agregaría uno para hacer la conversión de voltaje entre el lado USB y el lado de la batería, pero dado que la lógica ya está ahí, usarla tiene sentido. Aún así, lo aclararía primero con el fabricante.