Explicaré un caso concreto con la placa STM32F4 Discovery. La mejor y más potente placa de la familia Discovery.
 |
| Placa STM32F4 Discovery |
El problema
Hace ya un tiempo compré una placa de éstas y empecé a trabajar en el software. El entorno de trabajo, algún dia hablaré del él, está basado en Eclipse y usa compiladores GCC. Hasta el momento he probado con Code Sourcery y Yagarto. Para depurar empleo el servidor GDB que veía con la versión gratuita de Atollic True Studio for STM32.
Como todo iba bién con la placa compré una placa nueva, igualita a a la otra que ya tenía. Mi sorpresa fué que el debugger se colgaba al intentar comunicarse con el microcontrolador.
Para descartar que fuera una placa defectuosa intenté programar en la placa usando el software STLink Utility que proporciona gratuitamente ST para programar sus microcontroladores.
Nada más arrancar ya se veía que algo iba mal.
 |
| Aplicación STLink Utility |
El software era capaz de comunicar con el microcontrolador, pero no era capaz de averiguar de que micro se trata tal como se desprende de la frase "Unknown Device" arriba a la derecha de la pantalla. Fijémonos, luego diré porqué, en la identificación de la CPU que es 0x413
Al intentar programar el dispositivo las cosas se complican.
Es extraño, nunca habia visto este mensaje, le digo que adelante.
El programa es incapaz de programar el micro. Por lo visto está activada la protección que deshabitlita el bus JTAG para que no pueda extraerse el código del micro. Es extraño porque la placa es nueva.
La protección se configura con los llamados option bytes. Voy a la ventana pertinente y sale algo como ésto:
Parece que la protección de lectura está activada y la flash está protegida contra escritura. No se puede programar el micro y no se puede quitar la protección. No se puede usar el micro para nada que no sea usar el software de demostración que ya venía en la placa.
¡¡ Y la placa era nueva !!
La solución
Después de mucho buscar por internet a alguien que le hubiera pasado algo similar encontré esta referencia.Por lo visto la gente tenía problemas con la versión "Z" de la CPU. Las placas STM32F4 Discovery, por lo visto, llevaban antes CPUs de versión "A". El último batch de placas usa CPUs de versión "Z".
La siguiente figura muestra una CPU de versión A.
 |
| STM32F407 Version A |
A continuación se muestra una CPU de versión Z.
 |
| STM32F407 VersionZ |
Parece ser que en el paso de la versión A a la versión Z, la identificación de la CPU ha pasado de 0x411 a 0x413. A continuación se muestra el programa STLink Utility conectado a una CPU de versión "A" donde se vé como se identifica como 0x411 a diferencia de la identificación 0x413 de la versión "Z".
 |
| STLink Utility con STM32F4 versión "A" |
Misterio solucionado. Pero en esta historia hay algunos puntos muy molestos:
- Que ST envie placas STM32F4 Discovery incompatibles con versiones anteriores del software sin avisar de los posibles problemas de compatibilidad.
- Que ST no actualice la aplicación STLink cuando cambia los MCUs que soporta.
- Que la aplicación STLink no sea capaz de decir que no sabe como trabajar con el micro en lugar de hacernos creer que se ha habilitado la protección contra escritura.
Suerte que en la misma referencia que cité anteriormente se proporcionaba el link a una versión parcheada de STLink Utility para poder programar la placa.
Como información adicional de los cambios de la versión "A" a la versión "Z", parece que no hay más versiones intermedias. Éstos están documentados en el la Errata Sheet del microcontrolador. Lo que no se dice en este documento es la incompatibilidad que produce con las propias aplicaciones de ST.
Finalmente me alegra decir que la versión actual del servidor GDB de ATollic True Studio es capaz también de comunicarse con la CPU "Z" maldita.
No hay comentarios:
Publicar un comentario