Este es el esquemático de la Elephant Embedded S32K144. El problema actual es que el programa no arranca; la flash siempre aparece vacía. Cuando se suelta el botón de RESET, la tensión de RESET a tierra es de 1 V, lo cual claramente no es correcto.
El vendedor dice que el chip está bloqueado y que RESET tendrá salida. A continuación se muestra la forma de onda de RESET a tierra.
Pero, después de repasar con GPT todo el proceso de programación, me dijo que el chip no está bloqueado y que se puede grabar la flash, pero que inmediatamente después se borra.
Cuando le di todo el flujo a GPT, me dio la siguiente explicación: el bucle de reinicio del chip no se debe al watchdog, sino a un reinicio LOCKUP. La CPU con la flash vacía intenta obtener instrucciones en 0xFFFFFFFE → error de bus → HardFault (el handler también está en 0xFFFFFFFE) → recursión → LOCKUP → reinicio → y vuelve a repetirse, con un período de unos pocos cientos de microsegundos.
Pero ninguna de las soluciones que propuso sirvió. ¿Alguno de los expertos sabe cómo resolverlo?
¿El IO de reinicio se mantiene en nivel bajo repetidamente? ¿Será que el programa que grabaste usa este IO PTA5 (RST), lo lleva a nivel bajo por software y, además, no desactiva la función de reinicio de ese IO, por lo que se reinicia constantemente? Prueba a grabar un ejemplo normal.
El RESET de 1 V efectivamente tiene un problema. En condiciones normales, al soltar el botón de reinicio, RESET debería quedar llevado por una resistencia de pull-up interna o externa hasta casi VCC (3,3 V). Un valor de 1 V indica que o bien el pull-up es demasiado débil, o bien el chip está manteniendo activamente en bajo la señal de reinicio.
Mirando tu esquema, el pull-up de R7 de 2,2 k debería ser suficiente, pero ten en cuenta que el pin RESET del S32K144 es bidireccional: el propio chip también puede llevar activamente la línea de reinicio a bajo. Si realmente se trata de un bucle LOCKUP, el chip se reiniciará por sí solo cada pocos cientos de microsegundos, y la onda en diente de sierra de 1,64 kHz que ves en el osciloscopio probablemente sea eso.
Primero revisa estos puntos:
Mide el voltaje en ambos extremos de R7 para confirmar que la resistencia de pull-up está realmente conectada a VCC_MCU y que el voltaje es normal. A veces, una soldadura defectuosa en la alimentación de la placa de desarrollo o una salida inestable del LDO pueden hacer que el voltaje de pull-up no sea suficiente.
Desconecta el botón de reinicio y conecta directamente el pin RESET a VCC con un jumper para ver si el programa puede ejecutarse. Si funciona, el problema está en el circuito de reinicio; si sigue sin funcionar, puedes descartar el circuito de reinicio.
Conecta directamente con un depurador J-Link o PE, sin pasar por el OpenSDA integrado en la placa, y comprueba si puede identificar el ID del chip. A veces el depurador integrado puede interferir con el reinicio.
Comprueba VDDA y VREFH; si la alimentación analógica del S32K144 no está conectada o es inestable, también puede provocar comportamientos de reinicio extraños.
Sobre el bucle LOCKUP que mencionaba GPT, la lógica es correcta: una flash vacía puede comportarse así. Pero lo importante es por qué la flash está vacía. ¿El programador no llegó a escribirla, o se escribió pero luego se borró? Te recomiendo usar J-Flash o S32 Design Studio para conectarte directamente al chip y ver exactamente qué hay en la flash. Si la flash está efectivamente toda en FF, primero escribe un programa blink lo más simple posible y comprueba si puede ejecutarse. Si funciona, significa que el chip no está bloqueado y que el problema está en el flujo de programación; si no funciona, entonces considera si el chip está dañado o bloqueado.
La explicación de GPT es en realidad muy acertada. Una flash vacía en la S32K144 provoca una lectura desde una dirección no válida, lo que genera un HardFault, que escala a un Lockup y luego a un reinicio del sistema. El MCU está activando activamente ese pin de reinicio a nivel bajo, de ahí la forma de onda en diente de sierra de 1,64 kHz que estás viendo. Para solucionarlo, necesitas un depurador que admita „Connect under reset“. Si estás usando un J-Link, abre J-Link Commander e intenta el comando unlock kinetis. Detiene el núcleo antes de que intente ejecutar la instrucción incorrecta.
La misma placa, el mes pasado caí justo en esa trampa. Tu análisis con GPT en realidad es bastante acertado: se trata del bucle LOCKUP, pero no te dejes despistar por la forma de onda del reset.
La solución que encontré fue: mantener pulsado el botón de reset con la mano mientras se programa, soltarlo justo después de hacer clic en Download, para que el chip escriba el código antes de que se libere el reset. Porque una vez que entra en el bucle LOCKUP, la temporización de SWD se desordena; el depurador cree que la escritura se completó correctamente, pero en realidad no se escribió nada. Luego, al leer de vuelta, todo aparece como 0xFF, lo que parece como si estuviera “borrado”.
Además, revisa si tu archivo de arranque es específico para la S32K144. Si estás portando código desde una STM32, la posición de la tabla de vectores o el script de enlazado podrían no ser correctos. La dirección inicial de la memoria Flash de la S32K144 es 0x0000_0000, pero la tabla de vectores debe incluir un SP inicial válido y un Reset_Handler. Si esos dos valores son 0xFFFFFFFF, el chip entra en HardFault nada más liberarse el reset.
También mide si los 3,3 V son estables. A veces, esta placa no tiene suficiente potencia con la alimentación USB; cuando la tensión cae por debajo de 2,8 V, la escritura en Flash falla silenciosamente y también se manifiesta como que “no se puede programar”. Prueba con un cable USB más corto o con una fuente externa de 5 V.
¿Es una placa nueva? También podría ser que se reinicie continuamente porque no tiene firmware.
A mí me pasó algo similar antes con una ESP32S3: era un módulo nuevo, la memoria flash estaba vacía y seguía activando el reinicio. La solución para la ESP32 fue encenderla manteniendo pulsado el botón BOOT para entrar en modo de programación.
