Creo que los microcontroladores GD32 son clones de los de ST Microelectronics reales. Es bueno admitirlos, pero no debemos romper los microcontroladores compatibles existentes como en este número 761.

Para referencia: http://www.gigadevice.com/products/microcontrollers/gd32/arm-cortex-m4/mainstream-line/gd32f303-series/

Hola a todos,
Me he enfrentado al mismo problema con el chip CS32F103C8T6, que es el clon de STM32F103C8T6.

Tal vez sea valioso para el reportero, ya que tomó mucho tiempo descubrir qué está mal, agregué la identificación del núcleo de mi chip de la siguiente manera:

diff --git a/include/stlink.h b/include/stlink.h
index abacd12..582de7b 100644
--- a/include/stlink.h
+++ b/include/stlink.h
@@ -53,6 +53,7 @@ extern "C" {
     /* cortex core ids */
     // TODO clean this up...
 #define STM32VL_CORE_ID 0x1ba01477
+#define CS32VL_CORE_ID 0x2ba01477
 #define STM32F7_CORE_ID 0x5ba02477

     // Constant STM32 memory map figures
diff --git a/src/flash_loader.c b/src/flash_loader.c
index 7684680..72ed495 100644
--- a/src/flash_loader.c
+++ b/src/flash_loader.c
@@ -262,6 +262,7 @@ int stlink_flash_loader_write_to_sram(stlink_t *sl, stm32_addr_t* addr, size_t*
         loader_code = loader_code_stm32l;
         loader_size = sizeof(loader_code_stm32l);
     } else if (sl->core_id == STM32VL_CORE_ID
+            || sl->core_id == CS32VL_CORE_ID
             || sl->chip_id == STLINK_CHIPID_STM32_F3
             || sl->chip_id == STLINK_CHIPID_STM32_F3_SMALL
             || sl->chip_id == STLINK_CHIPID_STM32_F303_HIGH

Después de esto, todo funcionó como se esperaba. Dado que su chip es diferente, preste atención para verificar dos veces qué identificador de núcleo debe clonar.

Saludos, Volodymyr.

st-link (v2) está 'yendo a lugares', acabo de mostrar un nrf51822 (nordic semicon ble soc)
https://devzone.nordicsemi.com/f/nordic-qa/13869/openocd-promgram-nrf51822-with-st-link-v2-mini
https://devzone.nordicsemi.com/f/nordic-qa/12316/program-bluetooth-for-nrf51822-yunjia-board-with-stlink-v2
pero usé openocd aunque lol
el punto puede ser que es posible que necesitemos reelaborar st-link como módulos de canalización
st-link se está utilizando prácticamente como un dongle swd genérico. openocd creo que separa el dongle, es decir, st-link y el objetivo soc, por ejemplo, stm32f103 (que supongo que sería el predeterminado para esto) y, para el resto, es posible que deban ser 'complementos' o socs adicionales que pueden ser diferentes de stm32 (incluso sus clones)

Hola a todos,
Me he enfrentado al mismo problema con el chip CS32F103C8T6, que es el clon de STM32F103C8T6.

Tal vez sea valioso para el reportero, ya que tomó mucho tiempo descubrir qué está mal, agregué la identificación del núcleo de mi chip de la siguiente manera:

diff --git a/include/stlink.h b/include/stlink.h
index abacd12..582de7b 100644
--- a/include/stlink.h
+++ b/include/stlink.h
@@ -53,6 +53,7 @@ extern "C" {
     /* cortex core ids */
     // TODO clean this up...
 #define STM32VL_CORE_ID 0x1ba01477
+#define CS32VL_CORE_ID 0x2ba01477
 #define STM32F7_CORE_ID 0x5ba02477

     // Constant STM32 memory map figures
diff --git a/src/flash_loader.c b/src/flash_loader.c
index 7684680..72ed495 100644
--- a/src/flash_loader.c
+++ b/src/flash_loader.c
@@ -262,6 +262,7 @@ int stlink_flash_loader_write_to_sram(stlink_t *sl, stm32_addr_t* addr, size_t*
         loader_code = loader_code_stm32l;
         loader_size = sizeof(loader_code_stm32l);
     } else if (sl->core_id == STM32VL_CORE_ID
+            || sl->core_id == CS32VL_CORE_ID
             || sl->chip_id == STLINK_CHIPID_STM32_F3
             || sl->chip_id == STLINK_CHIPID_STM32_F3_SMALL
             || sl->chip_id == STLINK_CHIPID_STM32_F303_HIGH

Después de esto, todo funcionó como se esperaba. Dado que su chip es diferente, preste atención para verificar dos veces qué identificador de núcleo debe clonar.

Saludos, Volodymyr.

¿Puede decirme dónde agregó este código para flashear en el cs32?
Estoy usando Ubuntu para flashear el código y tengo el mismo problema de coreid, pero no tengo ni idea de dónde copiar el código anterior para resolver mi problema.
ty

Hola, Sizito.
El proyecto cambió un poco, pero es bastante fácil de alinear.

Cambie /include/stm32.h - para que se vea así:
// ID del núcleo de la corteza

definir STM32VL_CORE_ID 0x1ba01477

definir CS32VL_CORE_ID 0x2ba01477

definir STM32F7_CORE_ID 0x5ba02477

Cambie src / flash_loader.c - dentro de la función stlink_flash_loader_write_to_sram para que se vea como (~ línea 264):
} más si (sl-> core_id == STM32VL_CORE_ID
|| sl-> core_id == CS32VL_CORE_ID
|| sl-> chip_id == STLINK_CHIPID_STM32_F1_MEDIUM
|| sl-> chip_id == STLINK_CHIPID_STM32_F3

Entonces necesitas compilar la utilidad stlink con esos cambios y debería funcionar ...

Hola, Sizito.
El proyecto cambió un poco, pero es bastante fácil de alinear.

Cambie /include/stm32.h - para que se vea así:
// ID del núcleo de la corteza

definir STM32VL_CORE_ID 0x1ba01477

definir CS32VL_CORE_ID 0x2ba01477

definir STM32F7_CORE_ID 0x5ba02477

Cambie src / flash_loader.c - dentro de la función stlink_flash_loader_write_to_sram para que se vea como (~ línea 264):
} más si (sl-> core_id == STM32VL_CORE_ID
|| sl-> core_id == CS32VL_CORE_ID
|| sl-> chip_id == STLINK_CHIPID_STM32_F1_MEDIUM
|| sl-> chip_id == STLINK_CHIPID_STM32_F3

Entonces necesitas compilar la utilidad stlink con esos cambios y debería funcionar ...

Hola dexvovich,
Ty, por su ayuda, cambié los archivos como se indicó anteriormente, pero tengo un nuevo problema, que cuando uso el comando "make flash", el sistema está usando el contenido antiguo de "flash_loader.c".
Traté de reiniciar la PC pero tengo el mismo problema, él no está leyendo los nuevos cambios que hice.
Si tiene alguna idea de cómo obligarlo a usar el nuevo archivo, contácteme.
Ty

Sugeriría make clean y reconstruir para finalmente resolver este último, que no parece estar en el contexto del problema real. Si necesita más ayuda, no dude en enviar un nuevo ticket para esto. ;-)

@eugenesia : Es muy probable que no tenga acceso a esta MCU, pero a mí me parece que este dispositivo está relacionado de alguna manera con el CKS32F103 en términos de identificadores electrónicos. Además, el intento de resolver el problema es idéntico al primer enfoque para el CKS32F103, que introdujo la regresión (# 757). Así que esto también puede haberse resuelto con el # 805. ¿Qué piensa usted al respecto?

@rayslinky : ¿Puedes verificar esto con # 805?

@eugenesia : Es muy probable que no tenga acceso a esta MCU, pero a mí me parece que este dispositivo está relacionado de alguna manera con el CKS32F103 en términos de identificadores electrónicos. Además, el intento de resolver el problema es idéntico al primer enfoque para el CKS32F103, que introdujo la regresión (# 757). Así que esto también puede haberse resuelto con el # 805. ¿Qué piensa usted al respecto?

Hola @ Nightwalker-87, eché un vistazo a su cronología de eventos relacionados con el chip CS32 https://github.com/texane/stlink/issues/756#issuecomment -605629968. Es un poco una comedia de errores y habría continuado si no lo hubieras resuelto, así que gracias por hacerlo finalmente.

No creo que # 805 haya solucionado esto, ya que agrega detección para un ID de chip de STLINK_CHIPID_STM32_F1_MEDIUM (0x410). De https://github.com/texane/stlink/issues/769#issue -410536487, esta placa GD32 tiene el ID de chip 0x430 (no 0x410) y el ID de núcleo 0x2ba01477.

La identificación de la placa GD32 por su ID de chip probablemente no funcionaría. La última versión de _chipid.h_ describe el valor de ID de chip 0x430 como perteneciente a una placa STM32F1 STLINK_CHIPID_STM32_F1_XL . Por lo tanto, asignar ese valor a la placa GD32 (un clon de una placa STM32F303) rompería la identificación de la placa "STM32_F1_XL".

Podríamos intentar identificar esta placa por su ID de núcleo, pero sabemos que la ID de núcleo 0x2ba01477 es problemática ya que diferentes placas tienen esta ID. Es por eso que la corrección en el n. ° 757 introdujo una regresión en el n. ° 761.

Esto es lo que pude reunir sobre estos tableros:

Junta | Fabricante | Clon de | Core | ID de núcleo | ID de chip | Referencias
--- | --- | --- | --- | --- | --- | ---
CS32F103C8T6 | Sistema de claves de China (CKS) | STM32F103C8T6 | ARM Cortex-M3 | 0x2ba01477 | 0x410 ( STLINK_CHIPID_STM32_F1_MEDIUM ) | N.º 756
STM32F401 | ST | N / A (original) | ARM Cortex-M4 | 0x2ba01477 | ? (No tengo uno) | https://github.com/texane/stlink/issues/761#issuecomment -462068740
GD32F303VGT6 | GigaDevice | STM32F303 | Arm Cortex-M4 | 0x2ba01477 | 0x430 | https://github.com/texane/stlink/issues/769#issue -410536487 Página de producto GigaDevice GD32

Por los problemas que tuvimos, parece que no se puede confiar en las identificaciones de los chips de clonación. Tal vez deberíamos poder seleccionar el cargador flash usando argumentos de línea de comando en su lugar, como se sugiere aquí https://github.com/texane/stlink/issues/761#issuecomment -462868649?

Una solución provisional podría ser identificar una placa clonada por su ID de núcleo Y la ID de chip, que con suerte debería ser lo suficientemente única.

No creo que # 805 haya solucionado esto, ya que agrega detección para un ID de chip de STLINK_CHIPID_STM32_F1_MEDIUM (0x410). De # 769 (comentario) esta placa GD32 tiene ID de chip 0x430 (no 0x410) e ID de núcleo 0x2ba01477.

La identificación de la placa GD32 por su ID de chip probablemente no funcionaría. La última versión de chipid.h describe el valor de ID de chip 0x430 como perteneciente a una placa STM32F1 STLINK_CHIPID_STM32_F1_XL. Por lo tanto, asignar ese valor a la placa GD32 (un clon de una placa STM32F303) rompería la identificación de la placa "STM32_F1_XL".

Estás aquí. Para ser honesto, podría haberlo descubierto por mí mismo, si hubiera mirado más de cerca, no importa ...

Me gusta la idea de usar core-id + chip-id + leer en voz alta el fabricante para identificar las placas correctamente, tanto para placas originales como para placas clonadas. Quizás incluso haya un cuarto parámetro que pueda ayudar a distinguir. Hay que investigar un poco sobre eso. De todos modos, ese podría ser un enfoque para evitar bastantes identificaciones falsas. Sin embargo, esto podría estar codificado sin necesidad de argumentos en la línea de comandos.

La idea de tener una tabla de búsqueda similar al ejemplo anterior en nuestra documentación, también es deseable desde mi punto de vista. Puede basarse en el listado en /include/stlink/chipid.h y /include/stm32.h . Esto también podría reemplazar /doc/testedboards.md que creo que está (parcialmente) desactualizado. Sin embargo, la información disponible allí se puede incluir en dicha tabla.

Relacionado con # 903.