Saltar al contenido

Cómo hacer ping a un chip (detectar si un chip está conectado) con OpenOCD

Después de tanto trabajar hemos encontrado el resultado de esta problema que muchos usuarios de esta web tienen. Si tienes algún detalle que compartir puedes aportar tu comentario.

Solución:

Pregunta 1:

¿Esto es lo que necesitas? Depende. El sondeo automático, como se describe en la sección 10.7, solo es relevante para JTAG. Entonces, por sí solo, no cubrirá sus necesidades. Pero simplemente conectándose a través de SWD imprime la información correspondiente (el registro DPIDR en lugar del TAP IDCODE) por lo que de cualquier manera, puede obtener información similar sobre el chip en ambos protocolos.

Sin embargo, no estoy seguro de si eso es suficiente para ti. Si solo desea detectar que un chip (cualquier chip) responde, probablemente esto sea suficiente. Si también necesita identificar el chip en detalle, en general será necesario un examen más detallado, ya que los códigos de identificación que obtiene a través de ambos métodos identifican al diseñador del chip. Entonces, para todos los chips Cortex, básicamente obtendrá “ARM” en lugar del fabricante real del chip (por ejemplo, “ST”). Aunque los chips ST (y quizás otros fabricantes) tienen un TAP de escaneo de límites separado (es decir, solo JTAG) que proporciona un ST IDCODE real que se puede usar para la identificación del chip.

Sin embargo, dado que SWD es relevante solo para objetivos de tipo ARM Cortex (o más bien ADI v5), si puede usar SWD, también puede leer la tabla ROM de los componentes de depuración, que proporcionan, entre otras cosas, el fabricante del chip:

# Your JTAG adapter config
script interface.cfg

transport select swd
adapter_khz 100

swd newdap chip cpu -enable
dap create chip.dap -chain-position chip.cpu
target create chip.cpu cortex_m -dap chip.dap

init
dap info
shutdown

Salida para un STM32F103:

Info : SWD DPIDR 0x1ba01477
Info : chip.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : gdb port disabled
AP ID register 0x14770011
    Type is MEM-AP AHB
MEM-AP BASE 0xe00ff003
    Valid ROM table present
        Component base address 0xe00ff000
        Peripheral ID 0x00000a0410
        Designer is 0x0a0, STMicroelectronics
        Part is 0x410, Unrecognized 
        Component class is 0x1, ROM table
        MEMTYPE system memory present on bus
    ROMTABLE[0x0] = 0xfff0f003
        Component base address 0xe000e000
        Peripheral ID 0x04001bb000
        Designer is 0x4bb, ARM Ltd.
        Part is 0x0, Cortex-M3 SCS (System Control Space)
        Component class is 0xe, Generic IP component
    ROMTABLE[0x4] = 0xfff02003
        Component base address 0xe0001000
        Peripheral ID 0x04001bb002
        Designer is 0x4bb, ARM Ltd.
        Part is 0x2, Cortex-M3 DWT (Data Watchpoint and Trace)
        Component class is 0xe, Generic IP component
    ROMTABLE[0x8] = 0xfff03003
        Component base address 0xe0002000
        Peripheral ID 0x04000bb003
        Designer is 0x4bb, ARM Ltd.
        Part is 0x3, Cortex-M3 FPB (Flash Patch and Breakpoint)
        Component class is 0xe, Generic IP component
    ROMTABLE[0xc] = 0xfff01003
        Component base address 0xe0000000
        Peripheral ID 0x04001bb001
        Designer is 0x4bb, ARM Ltd.
        Part is 0x1, Cortex-M3 ITM (Instrumentation Trace Module)
        Component class is 0xe, Generic IP component
    ROMTABLE[0x10] = 0xfff41003
        Component base address 0xe0040000
        Peripheral ID 0x04001bb923
        Designer is 0x4bb, ARM Ltd.
        Part is 0x923, Cortex-M3 TPIU (Trace Port Interface Unit)
        Component class is 0x9, CoreSight component
        Type is 0x11, Trace Sink, Port
    ROMTABLE[0x14] = 0xfff42002
        Component not present
    ROMTABLE[0x18] = 0x0
        End of ROM table

Para los chips que no son de Cortex, obtendrá una buena identificación utilizando el JTAG TAP IDCODE solo con el sondeo automático, como en este ejemplo con un STR750 antiguo:

# Your JTAG adapter config
script interface.cfg

transport select jtag
adapter_khz 100

init
shutdown
Info : JTAG tap: auto0.tap tap/device found: 0x4f1f0041 (mfg: 0x020 (STMicroelectronics), part: 0xf1f0, ver: 0x4)

Pregunta 2:

Como se describió anteriormente, el “autoprobing” solo es relevante para JTAG, pero también obtiene la misma funcionalidad (leer un código de identificación) a través de SWD. Desafortunadamente, eso no te ayuda porque no tienes acceso a ninguno de los protocolos.

El problema es que utiliza ST-Link. A pesar de lo que la gente tiende a pensar, esto es NO a true Adaptador JTAG / SWD. Sí, habla tanto JTAG como SWD, pero oculta completamente el protocolo dentro del firmware del adaptador. Solo proporciona un conjunto de comandos de alto nivel para el host (OpenOCD), del tipo “Restablecer el objetivo”, “Paso del objetivo”, “Leer esta memoria”, etc. Como consecuencia, el soporte OpenOCD del ST-Link es un truco feo, donde se sienta en el objetivo capa en lugar de la adaptador capa. Por lo tanto, la mayoría de las funciones de nivel de adaptador, transporte o DAP de OpenOCD simplemente no existen y el sondeo automático en el sentido de OpenOCD es completamente irrelevante para su configuración.

Para flasheo simple y depuración GDB muy básica, el ST-Link funciona. Pero para algo más de bajo nivel, simplemente manténgase alejado del ST-Link. No es una buena combinación para OpenOCD.

Dicho esto, si todo lo que necesita es saber si hay un chip, en algunas configuraciones probablemente se pueda persuadir al ST-Link para que le brinde esa información, por ejemplo, con el siguiente archivo de configuración:

script interface/stlink.cfg

transport select hla_swd
adapter_khz 100

hla newtap chip cpu -enable
dap create chip.dap -chain-position chip.cpu
target create chip.cpu cortex_m -dap chip.dap

Obtendrás ya sea

Warn : UNEXPECTED idcode: 0x2ba01477

o

Error: init mode failed (unable to connect to the target)

El resto de las preguntas son irrelevantes junto con un ST-Link, por lo que asumiré que cambia a un adaptador JTAG / SWD real.

Pregunta 3:

El sondeo automático de JTAG, así como la lectura de DPIDR sobre SWD, es completamente no intrusivo. Para los objetivos de Cortex-M en general, la mayoría de los accesos de depuración al objetivo no son intrusivos, por lo que puede leer / escribir en la memoria, etc., mientras el objetivo se ejecuta casi sin afectarlo.

JTAG no define ni requiere que una señal de reinicio del sistema esté disponible en absoluto. El autoprobar funciona bien sin él, debería poder usar

reset_config none

Pregunta 4:

¿Quiere evitar en absoluto iniciar un servidor gdb / servidor telnet? Entonces puedes deshabilitarlos con la siguiente configuración:

gdb_port disabled
telnet_port disabled
tcl_port disabled

Sin embargo, si simplemente inicia OpenOCD para detectar un chip y luego lo apaga, es posible que iniciar temporalmente estos servicios no sea un problema.

Además, al menos el servidor GDB se inicia solo después de crear un objetivo, que no es necesario para realizar una sonda automática JTAG.

Resumen

Sí, debería poder hacer lo que quiera, pero quizás no con el ST-Link. Con un adaptador real, puede realizar un sondeo automático JTAG para imprimir los TAP detectados en la cadena de escaneo. Para SWD, OpenOCD siempre imprime el registro DPIDR detectado (y generalmente se rompe si no se encuentra un objetivo; la salida será diferente al menos).

La conexión / detección puede ser completamente no intrusiva, si el objetivo mismo lo admite, como lo hacen la mayoría de los de Cortex-M. Si el firmware de destino ha desactivado los pines de depuración o desactivado la lógica de depuración, es posible que deba mantener presionado o reiniciar por pulsos, según el destino.

Si conservas alguna duda o forma de beneficiar nuestro enunciado puedes dejar una nota y con mucho gusto lo leeremos.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *