Las pruebas de firmware USB PD deben demostrar que una versión propuesta conserva el comportamiento requerido en perfiles fijos, PPS, EPR, asignación de puertos y recuperación de fallas. La comparación más útil empareja la línea de base publicada con la compilación candidata bajo entradas idénticas y examina tanto los eventos del protocolo decodificados como la potencia entregada. Un número de versión modificado o un cargo telefónico exitoso no es esa comparación.
Para un proyecto de desarrollo de cargador, seleccione casos de regresión del comportamiento en el que puede influir el firmware. Conserve la evidencia de la versión anterior e identifique qué requisitos cambiaron deliberadamente. El alcance del programa USB-C PD y el proceso de control de calidad de WECENT pueden enmarcar una discusión sobre el lanzamiento; La aprobación del firmware aún depende del modelo exacto, la compilación, la configuración y la cobertura de regresión ejecutada. Distinga las mejoras planificadas de las diferencias inesperadas antes de que se publique el candidato.
¿Qué hace que una línea base de prueba de firmware USB PD sea útil?
Mantenga la construcción de referencia y sus entradas reproducibles.
Una línea de base debe preservar el firmware ejecutable y la configuración persistente, así como el seguimiento; sin esos artefactos, una aparente diferencia de comportamiento puede resultar imposible de reproducir de manera confiable.
Un informe antiguo sin la compilación o configuración ejecutable es una base débil. Registre la versión del controlador, la configuración del proyecto, la revisión del hardware y cualquier configuración persistente que sobreviva a una actualización. Conserve la lista de capacidad de origen relevante y las reglas de asignación de puertos, así como la cadena de versión. De lo contrario, una discrepancia en la configuración puede parecer una regresión del firmware.
La documentación del analizador Infineon CY4500-EPR proporciona un ejemplo de herramienta para capturar evidencia de protocolo. Corrija la versión del decodificador o documente cómo sus cambios afectan la comparación. Haga coincidir eventos por su significado y estímulo en lugar de exigir igualdad byte por byte en marcas de tiempo no relacionadas. Una línea de base repetible debería permitir al ingeniero decidir si una diferencia observada es intencionada, una variabilidad inofensiva o un cambio que viola un requisito.
Trate un rastro de diferencia como una rama para investigar. Las marcas de tiempo modificadas pueden reflejar una variación de ejecución normal; Los perfiles ofrecidos modificados o el comportamiento de recuperación pueden afectar el requisito. Compare eventos y resultados equivalentes antes de requerir capturas idénticas o descartar una diferencia como inofensiva.
¿Cómo se debe elegir la cobertura del dispositivo?
Cubra distintos comportamientos de protocolos y casos de uso de clientes.
Un receptor elegido para una vía de negociación no debe cubrir silenciosamente otra vía; retenga la razón por la que cada dispositivo físico o plantilla de prueba controlada pertenece a la matriz de regresión.
Los fracasos anteriores merecen casos de regresión nombrados cuando su desencadenante pueda reproducirse. Incluya la revisión exacta del dispositivo afectado o un representante justificado, junto con su versión de software y cable. Agregue casos para nuevas características y funciones que comparten la ruta del código modificado. Una compilación que cambia el manejo de solicitudes puede afectar más que el perfil único nombrado en la solicitud de cambio.
Registre si un caso utiliza un dispositivo receptor de energía real, un ejercitador de protocolo controlado o una carga electrónica. Cada uno responde una pregunta diferente. Los dispositivos reales exponen el comportamiento de interoperabilidad; los estímulos controlados hacen que las condiciones límite sean repetibles; La prueba de cargas eléctricas entregó energía bajo demandas definidas. La página de recursos USB-IF USB-C admite la selección de materiales de cumplimiento aplicables, pero una matriz de dispositivo interno no debe representarse como certificación USB-IF.
¿Con qué debería compararse la regresión de perfil fijo?
Compare perfiles anunciados, solicitudes aceptadas y entrega.
Verifique los perfiles inferiores tan deliberadamente como el perfil principal; una lista de capacidades modificada puede afectar el respaldo ordinario incluso cuando la demostración de potencia máxima todavía parece funcionar.
Comience con los perfiles requeridos por la especificación del producto. Si el candidato elimina o modifica intencionalmente una capacidad, identifique el cambio de requisito aprobado y los escenarios de cliente afectados. Pruebe el respaldo de menor potencia utilizado por los dispositivos receptores de energía representativos, así como la salida principal. Un éxito de máxima potencia no establece una selección correcta en los demás perfiles anunciados.
Conserve observaciones de corriente, voltaje y protocolo de la misma adquisición o de instrumentos sincronizados. Si se rechaza una solicitud, verifique si ese es el comportamiento requerido para sus parámetros. Si es aceptado, examinar el estado de entrega después de la transición correspondiente. Mantenga la precisión de la salida, el manejo de solicitudes y la recuperación como decisiones separadas para que un revisor de la versión pueda ver qué requisito amenaza realmente una diferencia inesperada.
Una caja de perfil fijo necesita el objeto solicitado real, no sólo el voltaje esperado. Si ambas construcciones producen el mismo voltaje a través de contratos diferentes, la instantánea eléctrica puede ocultar un cambio en la negociación. Conserve esa distinción cuando el dispositivo receptor de energía admitido dependa de una capacidad particular.
¿Cómo se pueden evaluar los cambios de PPS?
Límites de solicitud de reproducción y operación sostenida de PPS.
Utilice solicitudes repetibles para el manejo de límites y dispositivos receptores de energía reales para la interoperabilidad; conservan sus funciones separadas para que una demanda telefónica cambiante no invalide la comparación controlada del firmware.
La documentación de TI TPS25751 ofrece un ejemplo de componente de control compatible con PPS. Para el producto bajo revisión, verifique qué configuraciones y rutas de código definen el rango anunciado y el comportamiento actual. Compare una secuencia de solicitudes conocida en ambas versiones en lugar de depender únicamente de un teléfono cuyas solicitudes cambian con la temperatura o el estado de carga.
Luego, conserve un caso de dispositivo real apropiado para verificar la interoperabilidad según su patrón de solicitud real. Clasifique una diferencia como anuncio modificado, respuesta modificada, resultado entregado modificado o comportamiento sostenido modificado. Evaluar casos de potencia limitada utilizando el requisito aplicable; No asuma que todos los pares de tensión y corriente que parezcan válidos pueden suministrarse simultáneamente. Un registro de versión debe conectar cada diferencia observada con la configuración aprobada o un defecto documentado.
Divida la comparación de PPS en rango anunciado, manejo de solicitudes y resultado entregado. Un rechazo de límite puede ser correcto mientras que falla una solicitud válida dentro del rango. Es posible que ejecutar únicamente la ruta de carga normal del teléfono nunca ejerza los límites que controla el código modificado.
¿Qué comportamiento de EPR pertenece a la regresión?
Incluye entrada, operación mantenida y salida ordenada.
La prueba debería continuar más allá de la entrada en funcionamiento mantenido y la salida; una lectura de alto voltaje captura solo un estado dentro del ciclo de vida que la versión debe soportar.
La documentación de TI TPS26750A ilustra una implementación del controlador EPR. No establece la configuración ni el rendimiento de un cargador en particular. Elija casos para el modo implementado y la versión del protocolo aplicable. La calificación del cable, las solicitudes del dispositivo receptor de energía y el comportamiento de la ruta de energía deben ser lo suficientemente visibles para respaldar el resultado.
Un cambio en la administración de conexiones puede afectar el EPR incluso cuando las configuraciones de energía nominal siguen siendo idénticas. Compare eventos de mantenimiento y respuestas bajo entradas controladas y distinga una combinación no admitida de un caso fallido admitido. Preservar capturas de salida y reconectar. La pregunta de aceptación relevante es si el candidato maneja correctamente el ciclo de vida especificado, no si la mesa de pruebas obtuvo una vez la mayor potencia anunciada del producto.
La cobertura de entrada no es cobertura de mantenimiento. Un candidato puede establecer el estado EPR requerido y luego perderlo debido a un evento de mantenimiento o salida. Mantenga el mismo cable y dispositivo receptor de energía durante ese ciclo de vida, luego revise el comportamiento modificado más temprano en lugar de solo el voltaje final.
¿Cómo se deben reproducir los eventos multipuerto?
Corrija la combinación de carga y el orden de fijación.
Registre el dispositivo receptor de energía original mientras un segundo puerto cambia de estado; el hecho de que el nuevo dispositivo reciba energía no establece que el primer dispositivo haya mantenido la continuidad operativa requerida.
La nota de aplicación de carga USB-C multipuerto de TI explica un contexto de diseño para el control de energía compartida. Un candidato puede cambiar deliberadamente su política de asignación, pero el comportamiento resultante debe coincidir con el requisito del producto aprobado. Identifique qué dispositivo receptor de energía mantiene su contrato, cuál renegocia y cuál experimenta una interrupción mensurable.
Utilice más que una condición estática de todos los puertos conectados cuando el uso previsto incluya agregar o quitar dispositivos. Preservar el orden de estímulo y el estado inmediatamente anterior a cada evento. Un teléfono que aún se carga al final puede ocultar una breve interrupción que reinicia otro dispositivo. Compare la salida entregada y el estado operativo relevante del dispositivo receptor de energía, luego distinga un cambio de asignación aceptable de una regresión de continuidad no aprobada.
| Caso y revisión | Observación de referencia | Observación del candidato | evidencia de decisión |
|---|---|---|---|
| Perfil fijo requerido; construcciones identificadas | Solicitud requerida aceptada y salida verificada | Misma solicitud rechazada | Capacidad y seguimiento de solicitudes; investigar una regresión no intencionada |
| límite del PPS; construcciones identificadas | Límite aplicable manejado según lo especificado | Respuesta diferente ante el mismo estímulo. | Solicitud codificada y método aprobado; determinar si el cambio es intencional |
| Accesorio de segundo puerto; construcciones identificadas | Cambios de asignación dentro del comportamiento acordado. | El dispositivo receptor de energía activo se reinicia inesperadamente | Captura del estado del dispositivo receptor de energía y salida; decisión de continuidad requerida |
| Recuperación de fallas; construcciones identificadas | El siguiente archivo adjunto se realizó correctamente | El siguiente archivo adjunto no puede negociar | Rastreos de fallas y reconexión; el cierre del defecto sigue siendo incompleto |
¿Qué casos de fallo deberían conservarse después de una reparación?
Mantenga el disparador original y el requisito de recuperación.
Repita la siguiente conexión después de la respuesta al fallo; una parada protectora exitosa puede dejar un estado persistente no deseado que la prueba original de un solo evento no podría exponer.
Utilice métodos de laboratorio aprobados para mensajes no válidos, eventos de desconexión o estímulos de falla eléctrica. Registre qué instrumento generó el evento y cómo se controlaron sus parámetros. Una captura con formato incorrecto no es automáticamente evidencia de que el producto haya recibido el error deseado. Verificar la entrega del estímulo antes de interpretar la respuesta.
Compare la recuperación del candidato con el estado de retorno requerido: inactivo, un contrato restaurado u otra condición explícitamente definida. Repita la conexión relevante después de la recuperación para exponer el estado persistente del controlador. Una solución que sobrevive a un evento pero deja inutilizable el siguiente archivo adjunto está incompleta para ese requisito. Preservar la evidencia de falla original y el nuevo resultado juntos, con una explicación clara de por qué la recuperación observada respalda el cierre del defecto.
Un parche puede eliminar la falla visible y al mismo tiempo cambiar el respaldo en otro lugar. Reutilice el estímulo fallido original y luego examine los estados adyacentes alcanzados por el mismo camino de control. Esto es más informativo que volver a ejecutar una demostración de potencia máxima no relacionada y dar por completa la regresión.
¿Qué pruebas deberían autorizar un lanzamiento de firmware?
Aprobar explícitamente las coberturas definidas y las cuestiones no resueltas.
El artefacto de producción instalado debe coincidir con el candidato aprobado; Archive su configuración con la cobertura ejecutada para que las pruebas de ingeniería no se confundan con la versión de firmware publicada.
El paquete de lanzamiento debe identificar la compilación, la suma de verificación de configuración o el control de artefactos equivalente, el hardware compatible y la matriz ejecutada. Los resúmenes deben coincidir con las trazas y medidas subyacentes. Un caso marcado como aprobado debe tener un requisito y un resultado rastreables; un caso no ejecutado debe permanecer sin ejecutarse en lugar de inferirse de un dispositivo relacionado.
Cree una aprobación de lanzamiento en torno a diferencias, no a un recuento total de pases. Clasifique cada resultado modificado como previsto, como violación de requisitos o como no resuelto; un caso omitido permanece sin ejecutar. Acuerde esas responsabilidades en la especificación OEM/ODM. Mantenga el artefacto aprobado distinto de un candidato que simplemente aprobó un subconjunto conveniente. Para solucionar un defecto, conserve el activador original y las rutas afectadas adyacentes para que la aprobación demuestre la corrección sin ocultar una nueva reserva, asignación de puertos o regresión de recuperación.
Preguntas frecuentes
¿Puede un multímetro reemplazar una traza de regresión del firmware PD?
No. Puede proporcionar una lectura eléctrica útil en una condición particular, pero no muestra el intercambio de capacidades, el manejo de solicitudes o la secuencia de eventos que controla el firmware. Combine mediciones eléctricas adecuadas con una captura decodificada o un registro de controlador validado. Incluso un voltaje final estable puede seguir a un reinicio o retroceso inesperado. Las herramientas necesarias dependen del caso; el registro debe revelar tanto el comportamiento que se evalúa como el resultado entregado cuando ese resultado afecta la aceptación.
¿Deberían las actualizaciones de software del dispositivo cambiar la matriz de regresión?
Revíselos cuando puedan cambiar el patrón de solicitud del dispositivo receptor de energía, los modos admitidos o el comportamiento de inicio. Conserve el estado del dispositivo previamente aprobado siempre que sea posible y agregue un estado actualizado identificado por separado. De lo contrario, un dispositivo receptor de energía modificado puede hacer que el candidato a cargador parezca diferente de su línea base sin establecer una regresión del cargador. Explique la decisión de cobertura y preserve ambas identidades de software. La matriz debe reflejar las condiciones admitidas por el cliente y al mismo tiempo permitir que un ingeniero reproduzca la comparación original.
¿Qué debería suceder después de que se encuentre una regresión de firmware no resuelta?
Mantenga al candidato distinto de la versión aprobada y utilice el proceso de control de cambios del programa para tomar una decisión documentada sobre el manejo del hallazgo. Preservar la línea de base, el estímulo fallido y la cobertura afectada antes de considerar una corrección o reversión. La reutilización de una compilación anterior también requiere hardware y configuración compatibles; no asuma que es automáticamente apropiado para cada conjunto revisado. La aprobación de ingeniería debe explicar el artefacto aceptado y las limitaciones restantes en lugar de permitir que una diferencia no resuelta desaparezca en un recuento general de pruebas exitosas.
Conclusión: liberar un artefacto con su evidencia
Una versión de firmware es un cambio de comportamiento controlado. Compare el candidato exacto con una línea de base reproducible, cubra las rutas relevantes fijas, programables, de potencia extendida y de puertos compartidos, y conserve las fallas que anteriormente exponían las debilidades. Utilice dispositivos receptores de energía reales y estímulos controlados para sus diferentes propósitos en lugar de tratarlos como una cobertura completa. Antes de la publicación, separe los cambios previstos de las diferencias inexplicables e identifique cada caso no resuelto. Mantenga juntos el artefacto aprobado, la configuración y las capturas de soporte para que la versión instalada en producción pueda coincidir con la evidencia revisada por ingeniería.
{“@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [{“@type”: “Question”, “name”: “¿Puede un multímetro reemplazar una traza de regresión del firmware PD?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “No. Puede proporcionar una lectura eléctrica útil en una condición particular, pero no muestra el intercambio de capacidades, el manejo de solicitudes o la secuencia de eventos que controla el firmware. Combine mediciones eléctricas adecuadas con una captura decodificada o un registro de controlador validado. Incluso un voltaje final estable puede seguir a un reinicio o retroceso inesperado. Las herramientas necesarias dependen del caso; el registro debe revelar tanto el comportamiento que se evalúa como el resultado entregado cuando ese resultado afecta la aceptación.”}}, {“@type”: “Question”, “name”: “¿Deberían las actualizaciones de software del dispositivo cambiar la matriz de regresión?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Revíselos cuando puedan cambiar el patrón de solicitud del dispositivo receptor de energía, los modos admitidos o el comportamiento de inicio. Conserve el estado del dispositivo previamente aprobado siempre que sea posible y agregue un estado actualizado identificado por separado. De lo contrario, un dispositivo receptor de energía modificado puede hacer que el candidato a cargador parezca diferente de su línea base sin establecer una regresión del cargador. Explique la decisión de cobertura y preserve ambas identidades de software. La matriz debe reflejar las condiciones admitidas por el cliente y al mismo tiempo permitir que un ingeniero reproduzca la comparación original.”}}, {“@type”: “Question”, “name”: “¿Qué debería suceder después de que se encuentre una regresión de firmware no resuelta?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Mantenga al candidato distinto de la versión aprobada y utilice el proceso de control de cambios del programa para tomar una decisión documentada sobre el manejo del hallazgo. Preservar la línea de base, el estímulo fallido y la cobertura afectada antes de considerar una corrección o reversión. La reutilización de una compilación anterior también requiere hardware y configuración compatibles; no asuma que es automáticamente apropiado para cada conjunto revisado. La aprobación de ingeniería debe explicar el artefacto aceptado y las limitaciones restantes en lugar de permitir que una diferencia no resuelta desaparezca en un recuento general de pruebas exitosas.”}}]}