Recientemente traté de desarrollar una aplicación intermitente personalizada (basada en el módulo Python stm32loader) para microcontroladores STM32L073xx, pero me quedé atascado en un punto.
Esta biblioteca intenta obtener el tamaño de flash de thr micro porque para el mismo chip UID (0x447 - STM32L07x/L08x/L010) podemos tener diferentes tamaños de flash. La lib envía un comando para leer la memoria (cmd 0x11 0xEE) y aquí comienza mi problema:
Cuando trato de leer el tamaño del flash desde esta dirección, recibo la respuesta 0x1F (NACK) y no puedo continuar con el proceso.
Por supuesto, podría copiar el byte de tamaño de flash en algún lugar de la RAM antes de saltar al gestor de arranque del sistema o asumir algún tamaño de flash, pero entonces la aplicación no será robusta para todos los chips.
¿Cómo debe ser manejado de la manera adecuada? ¿Hay otra dirección donde se almacena el tamaño de flash?
Ahora puedo leer todo el contenido flash, pero hay un nuevo desafío. Intenté realizar un borrado masivo para preparar el flash para escribir contenido nuevo y sorpresa sorpresa... ¡el gestor de arranque devuelve NACK para cualquier tipo de borrado masivo!
Mi comunicación se ve así:
Ahora probé lo siguiente:
Ninguno de ellos funciona ... ¿alguna sugerencia?
No está claro por qué la lectura de la dirección 0x1FF8007C no funciona, obtengo el mismo error.
Sin embargo, experimentar con un Nucleo-L073RZ muestra que permitirá leer 128 bytes comenzando en la dirección 0x1FF80000, que tendrá el valor de tamaño de flash que busca como su penúltima palabra de 16 bits.
Pensando que podría ser un problema de compensación, probé lecturas en 0x1FF80000 + [0x70, 0x60, 0x40], ninguna de las cuales funcionó. Por el contrario, la lectura en 0x800007c funciona, por lo que se permiten compensaciones en general. Y como el tamaño de lectura se envía después del punto en el que la dirección está NAK, no hay problema si se requiere una lectura de 32 o 16 bits.
De todos modos, leer un bloque de 128 bytes debería resolver su problema.
Otra idea sería comenzar en una dirección cerca de la parte superior del tamaño de flash más grande y leer hacia abajo hasta que deje de fallar. O puede cargar un pequeño código auxiliar en la RAM y ejecutarlo. Pero parece que leer 128 bytes será la solución más sencilla.
Aparte, usando https://github.com/florisla/stm32loader (que parece ser lo que está en pypi, no dijiste lo que estabas usando) descubrí que tenía que reiniciar el chip cada vez que invocaba el programa, por lo que aparentemente no está dejando el gestor de arranque en el estado correcto. Aún así, es una mejora con respecto a otra herramienta que probé hace unos meses, que se negaba a comunicarse con el gestor de arranque L07x, aunque estaba bien con el L05x...
Si uno realmente quisiera pasar una tarde descendiendo por una madriguera de conejo, probablemente sería posible establecer un punto de interrupción antes de enviar el byte CRC de la dirección y rastrear la operación del cargador de arranque hasta la lógica que genera el ACK o NAK, pero como está en la ROM, todos ustedes probablemente aprendería es precisamente lo que está o (aparentemente erróneamente) no está permitido.
chris stratton
Voldi
Lundin
Voldi
chris stratton