La mejor manera de asignar espacio de memoria del cargador de arranque en el microcontrolador

Navega tus respuestas
3

Estoy confundido acerca de cómo asignar espacio de memoria del cargador de arranque en el microcontrolador pic18 y pasar un tiempo investigándolo y aterrizando aquí.

Pondré mi pregunta:

Tengo un controlador cuyo script de vinculador se ve así y define las secciones de memoria del controlador (que incluye el SFR, GPR y otras ubicaciones de inicio y finalización de la memoria).

Mi pregunta es ¿cómo se debe colocar el cargador de arranque en los microcontroladores ? ¿Deben mantenerse en el inicio de la memoria del programa? Tengo esta duda porque, por ejemplo, este tipo recomienda mantener el cargador de arranque en las ubicaciones de la memoria del programa 0x000-0xfff

enlace del cargador de arranque USB-HID

¿Deberían todos los cargadores de arranque reemplazar la dirección de inicio de la memoria de programación si queremos usar los cargadores de arranque? ¿Hay algo que debemos tener cuidado al asignar espacio para los cargadores de arranque?

/

Original linker fileof pic18 

/ File: 18f47j53_g.lkr
// Generic linker script for the PIC18F47J53 processor

#DEFINE _CODEEND _DEBUGCODESTART - 1
#DEFINE _CEND _CODEEND + _DEBUGCODELEN
#DEFINE _DATAEND _DEBUGDATASTART - 1
#DEFINE _DEND _DATAEND + _DEBUGDATALEN

LIBPATH .

#IFDEF _CRUNTIME
  #IFDEF _EXTENDEDMODE
    FILES c018i_e.o
    FILES clib_e.lib
    FILES p18f47j53_e.lib

  #ELSE
    FILES c018i.o
    FILES clib.lib
    FILES p18f47j53.lib
  #FI

#FI

#IFDEF _DEBUGCODESTART
  CODEPAGE   NAME=page       START=0x0               END=_CODEEND
  CODEPAGE   NAME=debug      START=_DEBUGCODESTART   END=_CEND        PROTECTED
#ELSE
  CODEPAGE   NAME=page       START=0x0               END=0x1FFF7
#FI

CODEPAGE   NAME=config     START=0x1FFF8           END=0x1FFFF        PROTECTED
CODEPAGE   NAME=devid      START=0x3FFFFE          END=0x3FFFFF       PROTECTED

#IFDEF _EXTENDEDMODE
  DATABANK   NAME=gpre       START=0x0               END=0x5F
#ELSE
  ACCESSBANK NAME=accessram  START=0x0               END=0x5F
#FI

DATABANK   NAME=gpr0       START=0x60              END=0xFF
DATABANK   NAME=gpr1       START=0x100             END=0x1FF
DATABANK   NAME=gpr2       START=0x200             END=0x2FF
DATABANK   NAME=gpr3       START=0x300             END=0x3FF
DATABANK   NAME=gpr4       START=0x400             END=0x4FF
DATABANK   NAME=gpr5       START=0x500             END=0x5FF
DATABANK   NAME=gpr6       START=0x600             END=0x6FF
DATABANK   NAME=gpr7       START=0x700             END=0x7FF
DATABANK   NAME=gpr8       START=0x800             END=0x8FF
DATABANK   NAME=gpr9       START=0x900             END=0x9FF
DATABANK   NAME=gpr10      START=0xA00             END=0xAFF
DATABANK   NAME=gpr11      START=0xB00             END=0xBFF

#IFDEF _DEBUGDATASTART
  DATABANK   NAME=gpr12      START=0xC00             END=_DATAEND
  DATABANK   NAME=dbgspr     START=_DEBUGDATASTART   END=_DEND           PROTECTED
#ELSE //no debug
  DATABANK   NAME=gpr12      START=0xC00             END=0xCFF
#FI

DATABANK   NAME=gpr13      START=0xD00             END=0xDFF
DATABANK   NAME=gpr14      START=0xE00             END=0xEAF
DATABANK   NAME=sfr14      START=0xEB0             END=0xEFF          PROTECTED
DATABANK   NAME=sfr15      START=0xF00             END=0xF5F          PROTECTED
ACCESSBANK NAME=accesssfr  START=0xF60             END=0xFFF          PROTECTED

#IFDEF _CRUNTIME
  SECTION    NAME=CONFIG     ROM=config
  #IFDEF _DEBUGDATASTART
    STACK SIZE=0x100 RAM=gpr11
  #ELSE
    STACK SIZE=0x100 RAM=gpr12
  #FI
#FI
    
pregunta Rookie91

2 respuestas

3

Siempre he puesto mis cargadores de arranque PIC 18 al final de la memoria del programa. La razón por la que no puede ponerlos al principio es que aquí es donde también están los vectores de interrupción. Suponiendo que su aplicación utiliza interrupciones, ya que la mayoría no quiere que el gestor de arranque sea el propietario de esa sección de memoria.

Cree el cargador de arranque como un proyecto separado que tenga una dirección de inicio fija conocida cerca del final de la memoria. Utilizo un archivo de inclusión para definir las cosas en las que tanto la aplicación principal como el cargador de arranque deben estar de acuerdo, como la dirección de inicio del cargador de arranque y dónde debe saltar el cargador de arranque para ejecutar la aplicación principal. Estas deben ser direcciones fijas, ya que las diferentes versiones del gestor de arranque y la aplicación principal deben poder trabajar juntas.

La ejecución tiene que ir al cargador de arranque al reiniciar. Eso significa una instrucción GOTO en la ubicación 0 a la dirección de inicio fija conocida del cargador de arranque. Dado que la ubicación 0 está en la imagen principal de la aplicación, esto es algo que el código principal de la aplicación debe proporcionar.

Con este tipo de proyecto, la aplicación principal generalmente contiene un cargador. Durante su funcionamiento normal, se comunica con cualquier cosa que pueda proporcionar una nueva imagen de aplicación. Esta nueva imagen de la aplicación se almacena en una EEPROM externa o aproximadamente la segunda mitad de la memoria del programa. Todo el código complicado para comunicarse con el host y obtener la nueva imagen de la aplicación se encuentra en la aplicación principal.

El cargador de arranque es entonces un pequeño fragmento de código al final de la memoria que se ejecuta desde el reinicio. Compara la aplicación principal y las versiones de imágenes cargadas y ejecuta sumas de comprobación en ellas. Bajo las condiciones adecuadas, copia la nueva imagen de la aplicación en el área principal de la aplicación y luego la ejecuta. Por supuesto, nunca ejecuta una aplicación principal que tiene una suma de comprobación errónea.

Hay una pequeña vulnerabilidad con esto. Para actualizar la imagen principal de la aplicación, el gestor de arranque debe borrar y luego sobrescribir el primer bloque de borrado de la memoria del programa. Desafortunadamente, ahí es donde está el vector de reinicio. Si se produce un fallo de alimentación o una falla en los pocos milisegundos cuando el GOTO en el vector de reinicio no está allí, entonces el PIC es un brindis y solo se puede recuperar con un programador externo. Afortunadamente, esa es una ventana muy pequeña de vulnerabilidad, con las probabilidades de que suceda realmente muy pequeña. Tenga en cuenta que se puede recuperar un error al borrar / escribir cualquiera de las otras páginas de borrado. Mientras GOTO esté en el vector de reinicio, el gestor de arranque se volverá a ejecutar, la suma de comprobación de la aplicación principal fallará e intentará volver a escribir la aplicación principal desde la imagen de la aplicación almacenada.

    
respondido por el Olin Lathrop
0

Los cargadores de arranque, por definición, deben llamarse antes del firmware regular para que puedan elegir ejecutar o pasar el control de inmediato al firmware principal.

En la mayoría de los dispositivos, esto significa que el gestor de arranque está escrito en la dirección de inicio ( 0x0000 ) y la imagen del firmware principal está compensada por una cantidad fija. Por ejemplo, el firmware principal puede estar en la siguiente página de flash para que el cargador de arranque no corra peligro de borrarse al actualizar el firmware, y hay suficiente espacio para que el código del cargador de arranque crezca un poco sin tener que volver a compilar el firmware principal para mover su dirección de inicio. / p>     

respondido por el John U

Lea otras preguntas en las etiquetas

Cálculo de la latencia para chips ADC muestreo de audio de 8 kHz frente a 48 kHz y expectativas de ruido