Estoy tratando de armar un gestor de arranque simple en el extremo superior del flash de un atmega8. El cargador se comunica con minicom a través del protocolo XMODEM, comprueba los errores, escribe las páginas flash correspondientes y las verifica. Todo esto está probado y funcionando.
Lo que no funciona es ejecutar la aplicación después de que se haya flasheado. Tengo 4 casos de prueba.
Si el archivo de entrada es 1kB de 0x00 o 0x01 bytes, después de un reinicio en frío, la ejecución del programa parece comenzar en el cargador de arranque, aunque el bit BOOTSEL está configurado para comenzar en la dirección flash 0x0000 y el cargador está en 0x1800.
Si el archivo de entrada es un archivo binario de un programa real, el chip se bloquea y no es posible la comunicación. Lo he intentado con aplicaciones muy simples y bastante complejas, y el resultado es el mismo.
avr-gcc app.c -o app.out
avr-objcopy -j .text -j .data -O binary app.out app.bin # doesn't work
avr-objcopy -j .text -j .data -O ihex app.out app.hex # works via an isp
Si bien se ha verificado que ambos programas funcionan al cargar el archivo .hex a través de un programador del sistema, la carga de los resuts de .bin biles en la secuencia explicada.
Por ejemplo, aquí están los primeros bytes de la aplicación muy simple:
00000000 12 c0 24 c0 23 c0 22 c0 21 c0 20 c0 1f c0 1e c0 |..$.#.".!. .....|
Esto es big-endian, se está convirtiendo a small-endian por el cargador de arranque. El opticode de un RJMP es 1100 kkkk kkkk kkkk donde k es un desplazamiento de hasta 2kB. Así, 12 c0 se convierte en c0 12 , que se convierte en 1100 0000 0001 0010 . Así que la tabla de vectores está ahí.
¿Qué podría estar mal? Se me acabaron las ideas. Y mis únicas ayudas de depuración son printf() sobre uart y parpadea un led - no hay JTAG disponible. ¿Dónde debo investigar para la solución?