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.