Desde el laboratorio RDN
Acer Extensa ES1-572: el EC bloqueaba una batería compatible por su nombre
Esta Acer Extensa ES1-572 llegó con un síntoma directo: funcionaba conectada al cargador, reconocía la batería, pero no la cargaba. La revisión del circuito no mostraba una explicación suficiente y cambiar componentes a ciegas podía dejar exactamente el mismo problema.
La causa estaba en una decisión del firmware del controlador embebido —el EC—: la batería era funcional, pero su nombre de modelo no aparecía en una lista interna de packs admitidos.
Una falla de carga que parecía electrónica
La motherboard B5W11 LA-E061P utiliza un cargador controlado por SMBus. Durante la medición identificamos el integrado que realmente respondía en el bus y leímos tanto sus registros como la información de la batería.
El resultado era contradictorio sólo en apariencia. La batería Panasonic AP19B5L informaba temperatura normal, estado válido, ausencia de alarmas y una solicitud concreta de corriente y tensión. El cargador también reconocía el adaptador y tenía programado su límite de entrada. Sin embargo, el EC mantenía activo Charge Inhibit y dejaba en cero la corriente y la tensión de carga.
Eso mostraba el efecto, pero todavía no explicaba la causa. El siguiente paso fue separar una falla de potencia de una decisión de control.
La prueba que separó el hardware del firmware
Realizamos una prueba manual limitada y supervisada sobre el cargador. Se programó una corriente reducida, se estableció la tensión solicitada por la batería y se retiró temporalmente la inhibición.
La respuesta fue inmediata: la batería comenzó a recibir corriente, dejó de informar descarga y su tensión subió. Medio segundo después, otro maestro del bus —coherente con la intervención del EC— volvió a activar Charge Inhibit.
La prueba confirmó dos cosas importantes. El cargador, los MOSFET, el shunt y el camino hacia la batería podían trabajar; al mismo tiempo, el EC estaba imponiendo activamente la detención. Forzar el registro de manera continua habría significado pelear contra el control de la notebook, no reparar la causa.
Qué encontramos dentro del EC oficial
Obtuvimos el paquete oficial correspondiente a la plataforma y extrajimos el firmware del EC de forma pasiva, sin ejecutar el actualizador en otra computadora. El análisis mostró una tabla de comandos Smart Battery que incluía la consulta DeviceName, utilizada por una batería para informar su nombre de modelo.
Junto a esa lógica aparecía una lista compacta de cinco identificadores de batería. El nombre AP19B5L no estaba incluido.
La coincidencia era demasiado precisa para ignorarla: la batería respondía correctamente, el EC consultaba su nombre, la lista no la contemplaba y el mismo EC reponía la inhibición después de que el cargador comenzaba a trabajar.
Una modificación mínima sobre una base oficial
Preparamos una variante a partir del EC oficial de la placa. No mezclamos datos del firmware viejo ni trasladamos identidades de otra notebook. Para conservar el tamaño y no desplazar código, sustituimos una entrada de siete caracteres de la lista por AP19B5L.
La diferencia binaria quedó limitada al campo de texto previsto: cuatro bytes efectivos. No se desactivaron sensores, límites eléctricos ni rutinas de protección. Tampoco se alteró el controlador del cargador.
Resultado: la Acer volvió a cargar
Después de programar la variante, la notebook comenzó a cargar la AP19B5L sin que una herramienta externa tuviera que forzar los registros del cargador. Esa prueba en placa confirmó la relación causal: la validación por nombre de batería intervenía en el bloqueo.
El caso también evitó un reemplazo innecesario del integrado cargador. El componente había demostrado que podía regular y entregar corriente cuando recibía una programación válida; cambiarlo no eliminaba la política que el EC escribía por SMBus.
El efecto práctico de una lista cerrada
Una comprobación de identidad puede formar parte del diseño de un fabricante. En este equipo, sin embargo, la batería entregaba datos coherentes, no reportaba alarmas y aceptaba carga dentro de las condiciones programadas. La única modificación necesaria para recuperar la función fue permitir su nombre dentro de una lista oculta.
El efecto práctico es una restricción de compatibilidad por firmware: una batería eléctricamente funcional queda bloqueada por no coincidir con un identificador autorizado. Es un buen ejemplo de por qué el derecho a reparar también depende de poder observar y comprender las decisiones implementadas en el software embebido.
No es una receta universal
Este resultado corresponde a una plataforma, una revisión de EC y una batería concretas. Aplicar el mismo cambio sobre otro firmware sin identificar placa, versión, estructura y compatibilidad eléctrica puede dejar el equipo sin funcionar o habilitar un pack que no corresponde.
En una reparación de este tipo hay que diferenciar claramente el archivo preparado, la programación, la verificación de lectura y el resultado real en la notebook. Tampoco distribuimos dumps con datos de equipos o clientes.
Si tu notebook reconoce la batería pero no carga, podés conocer nuestro servicio de BIOS y electrónica avanzada o consultar al laboratorio indicando marca, modelo, síntoma y antecedentes.