Cargando un archivo HEX con PICkit 2

0

Estoy tratando de cargar un archivo hexadecimal, generado a partir de múltiples archivos fuente C con xc8 en Proteus, en un PIC18F4520. Por lo general, no tengo ningún problema al hacer esto, pero ayer porté un código de pantalla Arduino TFT al PIC e intenté cargar y probar algunas funciones básicas de la pantalla. Se cargó el HEX y el PIC condujo la pantalla perfectamente, excepto por un problema con el color del texto. Revisé el código y descubrí que el problema se debía a una variable que declaré accidentalmente como uint8_t en lugar de uint16_t , lo que provocó que el color se truncara. La variable es una de un grupo de variables static con alcance de archivo:

static uint8_t _width    = ST7735_TFTWIDTH;
static uint8_t _height   = ST7735_TFTHEIGHT;
static uint8_t rotation  = 1;
static uint8_t cursor_y  = 0;
static uint8_t cursor_x  = 0;
static uint8_t textsize  = 1;
static uint8_t textcolor = 0xFFFF;  // this is the relevant line
static uint8_t text_wrap      = 1;
static uint8_t colstart = 0, rowstart = 0;

Corrigí la declaración y construí un nuevo HEX en Proteus e intenté volver a cargarlo con la aplicación PICkit 2. Cuando importé el archivo hexadecimal para comenzar la carga, recibí la advertencia: Hex file loaded is larger than device , lo cual no tenía ningún sentido ya que el resumen de la memoria es:

Memory Summary:
    Program space        used  17DBh (  6107) of  8000h bytes   ( 18.6%)
    Data space           used    6Dh (   109) of   600h bytes   (  7.1%)
    Configuration bits   used     7h (     7) of     7h words   (100.0%)
    EEPROM space         used     0h (     0) of   100h bytes   (  0.0%)
    ID Location space    used     8h (     8) of     8h bytes   (100.0%)
    Data stack space     used     0h (     0) of   580h bytes   (  0.0%)

Esta vez, al inspeccionar la salida xc8 en MPLABX, encontré este mensaje en la parte inferior: Warning: C:/.../train85.X.production.hex contains code that is located at addresses that do not exist on the PIC18F4520 . Esto se correlaciona con otras respuestas que encontré en línea; Parece que el código se está escribiendo en direcciones no existentes. Los métodos utilizados por otros para resolverlo parecen variados: algunos hicieron cambios en la disposición de las variables CONFIG, haciéndolos más compactos (que he intentado), mientras que otros editaron el HEX en sí manualmente. Algunas observaciones que pueden ser pertinentes:

  • Si deshago esa única corrección en la declaración anterior, la advertencia ya no está presente.
  • Hay 2 matrices grandes para detalles de fuentes, que se almacenan en la memoria del programa con la palabra clave const . Tienen un tamaño aproximado de 2.4k y se accede a ellos mediante punteros en estructuras.
  • Si muevo una de las matrices de fuentes a la memoria de datos eliminando el calificador const , la advertencia también desaparece.
  • Cuando ignoré la advertencia y subí el HEX al PIC con la aplicación PICkit, no parecía haber ningún problema; la pantalla TFT se manejó perfectamente y se resolvió el problema del color del texto.

Los archivos HEX, SYM, MAP y inicio ASM, antes y después de la corrección, se encuentran aquí en caso de que los necesites. No puedo publicar mi código aquí ya que hay varios archivos, pero puedo proporcionarle un enlace, si es necesario.

En caso de que mi pregunta no fuera clara, necesito saber la causa exacta de la advertencia, ya que se relaciona con mi código (HEX) y con una solución . ¿Es seguro ignorarlo, como hice yo? Gracias de antemano.

    
pregunta TisteAndii

1 respuesta

1

Creo que sé el problema. En su primer archivo hexadecimal, la alineación es correcta en 2 bytes, con 16 bytes en cada línea. Las primeras direcciones son (en hexadecimal):

6830
6840
6850
6860
6870
6880
6890
68A0

Observe cómo las direcciones aumentan en incrementos de 16 bytes (10 h), pero de manera crucial, observe que el dígito más bajo siempre es cero (hablando estrictamente un múltiplo de 2).

En el archivo hexadecimal corregido, las direcciones son:

6829
6839
6849
6859
6869
6879
6889
6899
68A9

Aquí ya no están correctamente alineados. Observe que el dígito inferior es no un múltiplo de 2, es 9.

Esto es un problema simplemente porque la memoria del programa del PIC está organizada en fragmentos de 2 bytes (16 bits): cada instrucción es de 16 bits o de 32 bits IIRC.

Técnicamente, el archivo hexadecimal es correcto, sin embargo, confundirá el acceso de las herramientas porque técnicamente la dirección 0x6829 no existe (0x6828 y 0x682A sí). El software PICKit realineará el archivo hexadecimal cuando lo abra, esencialmente agregando una palabra 0xFF adicional al principio para realinear los datos al lugar correcto, y como resultado, la carga funciona y el programa funciona bien.

En cuanto a por qué está sucediendo, realmente no tengo una pista más allá de un error en una cadena de herramientas que ya tiene fallas en el mejor de los casos (¡la razón por la que me rendí con los PIC y me decidí por los AVR!). p>

Puede haber una configuración en algún lugar del proyecto para seleccionar la alineación del archivo hexadecimal. De lo contrario, quizás podría intentar agregar una variable de tamaño de byte adicional en la memoria del programa (o hacer que una existente tenga un byte de tamaño adicional) y ver si eso engaña a la cadena de herramientas para realinear el archivo hexadecimal.     

respondido por el Tom Carpenter

Lea otras preguntas en las etiquetas