Fallos en actualización de firmware vía USB DFU: modo bootloader, transferencias de control, timeouts y reconexiones

Los fallos en la actualización de firmware son estresantes porque un dispositivo puede desaparecer, entrar en modo bootloader, reconectarse con un VID/PID distinto o quedarse atascado en "initializing", "erasing", "downloading" o "rebooting". Los usuarios buscan "USB DFU failed", "firmware update stuck initializing", "USB bootloader not detected", "DFU device not found" y "firmware update timeout" porque el updater rara vez muestra la state machine USB.

Los flujos de USB Device Firmware Upgrade se suelen construir sobre transferencias de control y transiciones de estado del dispositivo. El updater puede hablar con el firmware de aplicación normal, ordenar un reboot al modo bootloader, esperar a que enumere otro dispositivo USB, mandar bloques de firmware, pedir status y luego ordenar un detach o reset.

Bus Scope ayuda porque cada etapa es visible en el bus si se captura desde el principio.

La actualización de firmware suelen ser dos dispositivos

Muchos productos enumeran como un dispositivo USB en operación normal y como otro distinto en modo bootloader. El VID/PID, el product string, las interfaces y el binding de driver pueden cambiar.

La secuencia puede ser:

1. El dispositivo normal está conectado.
2. El updater manda el comando de entrar al bootloader.
3. El dispositivo se desconecta.
4. El dispositivo bootloader enumera.
5. El updater manda bloques de DFU download.
6. El dispositivo reporta status.
7. El dispositivo se resetea al modo normal.

Si el usuario empieza la captura cuando el dispositivo ya desapareció, la transición importante ya no está.

Puntos de fallo habituales

Las actualizaciones DFU fallan cuando:

• No se llega a entrar al modo bootloader.
• El bootloader enumera pero el driver no enlaza.
• El updater espera un VID/PID y el dispositivo expone otro.
• La transferencia de control hace STALL.
• El tamaño de bloque de firmware es incorrecto.
• El dispositivo hace timeout durante el erase.
• El polling de status es demasiado agresivo.
• El dispositivo se desconecta durante la descarga.
• Un problema de cable o power provoca un reset.
• Una comprobación de seguridad o versión rechaza la imagen.

El updater puede reportar todo esto como "firmware update failed".

Evidencia en transferencias de control

Las operaciones de clase DFU usan transferencias de control. Una traza puede enseñar si el updater mandó datos de download, pidió status, limpió estado o se topó con un STALL.

Busca:

• DFU_DNLOAD
• DFU_UPLOAD
• DFU_GETSTATUS
• DFU_CLRSTATUS
• DFU_ABORT
• Reset o desconexión del dispositivo.
• STALL en endpoint cero.

Si una transferencia de control hace STALL siempre en el mismo bloque, la validez de la imagen, el block size, el comportamiento de erase/write de flash o un bug del bootloader cobran fuerza.

Timing de reconexión

Tras entrar al modo bootloader, el updater tiene que esperar a la re-enumeración. Si busca demasiado pronto, puede decir "device not found" aunque el bootloader aparezca un segundo después.

Una traza del bus enseña el timing:

• Tiempo de detach del dispositivo normal.
• Tiempo de attach del bootloader.
• Lecturas de descriptores.
• Binding de driver.
• Primera petición DFU.

Esa evidencia ayuda a separar un timeout del updater de un fallo del dispositivo.

Problemas de binding de driver

En Windows, un bootloader puede necesitar un driver distinto al del dispositivo normal. En Linux, los permisos pueden variar según el VID/PID. En macOS, el comportamiento de clase puede cambiar otra vez.

Si el bootloader enumera bien pero el updater no puede abrirlo, el problema está por encima de la enumeración USB básica. Si el bootloader nunca enumera, depura primero firmware, cable, reset y power.

Checklist de depuración

Usa este proceso:

1. Captura antes de arrancar el updater.
2. Apunta los descriptores del dispositivo normal.
3. Captura el comando de entrar al bootloader.
4. Observa la desconexión y la re-enumeración del bootloader.
5. Apunta el VID/PID y los descriptores del bootloader.
6. Inspecciona las transferencias de control DFU.
7. Encuentra el primer STALL, timeout, reset o respuesta ausente.
8. Compara el número de bloque fallido si es repetible.
9. Comprueba binding de driver y permisos tras la enumeración.
10. Conserva toda la línea de tiempo de la actualización antes de recortarla.

Diagnóstico final

Los fallos de USB DFU son fallos de state machine. La causa raíz puede estar en la entrada al bootloader, la re-enumeración, el binding de driver, el comportamiento de las transferencias de control DFU, el block size, el timing de flash, la validación de imagen o el timing de reset.

Bus Scope ayuda a exponer la actualización de firmware como evidencia USB, no solo como una barra de progreso que se para.