Administrar consideraciones de memoria y latencia

Artículo
08/09/2023

En este tema se describen consideraciones básicas de uso de memoria y latencia para aplicaciones en tiempo real que se ejecutan en el chip MT3620.

Nota

Para obtener más información sobre la configuración de memoria o DMA, consulte la hoja de datos MT3620 publicada de MediaTek; si quedan preguntas, puede solicitar la "Hoja de datos MT3620 M4" de Avnet por correo electrónico Azure.Sphere@avnet.com.

Diseño de memoria en los núcleos en tiempo real

En la tabla siguiente se resume la memoria disponible en los núcleos en tiempo real:

Tipo de memoria	Dirección base
TCM	0x00100000
Flash XIP	0x10000000
SYSRAM	0x22000000

Cada núcleo en tiempo real tiene 192 KB de memoria estrechamente acoplada (TCM), que se asigna en tres bancos de 64 KB a partir de 0x00100000. Los accesos TCM son rápidos, pero sólo el núcleo en tiempo real puede acceder a la memoria. TCM no se puede compartir con una aplicación de alto nivel o con una aplicación capaz en tiempo real (RTApp) que se ejecute en un núcleo diferente.

Cada núcleo en tiempo real también tiene 64 KB de SYSRAM, que se asigna empezando en 0x22000000. El controlador DMA también puede dirigirse a SYSRAM, para que los periféricos puedan acceder a él. Los accesos a SYSRAM desde el núcleo en tiempo real son más lentos que los accesos a TCM. Al igual que con TCM, SYSRAM no se puede compartir con otra aplicación.

La memoria flash execute-in-place (XIP) se comparte con aplicaciones de alto nivel. Una ventana en la asignación XIP del flash es visible para cada núcleo en la dirección 0x10000000. El sistema operativo configura la asignación XIP antes de iniciar la aplicación si el archivo ELF de la aplicación contiene un segmento que tiene las siguientes propiedades:

La dirección de carga (como se especifica en la columna VirtAddr del encabezado del programa) es igual a 0x10000000
El desplazamiento y el tamaño del archivo (como se especifica en los campos FileSiz y MemSiz del encabezado del programa) se ajustan al archivo ELF de la aplicación

Si un encabezado de programa con estas propiedades está presente en el archivo ELF de la aplicación, la ventana XIP se colocará para que el segmento sea visible en 0x10000000. El archivo no puede tener más de un segmento XIP y debe apuntar a 0x10000000; no puede especificar ninguna otra dirección.

Implementación de ELF

Las imágenes RTApp deben ser archivos ELF. La imagen ELF se ajusta en un paquete de imagen de Azure Sphere y se implementa como una aplicación. Para cargar la aplicación, azure Sphere OS inicia un cargador ELF que se ejecuta en el núcleo en tiempo real. El cargador procesa cada segmento LOAD en el archivo ELF y lo carga en el tipo de memoria indicado por la dirección virtual en el encabezado del programa.

Utilice arm-none-eabi-readelf.exe -l (minúscula L), que forma parte del GNU Arm Embedded Toolchain, para mostrar los encabezados de programa de su aplicación. La columna de dirección virtual (VirtAddr) que aparece en el encabezado indica la dirección de destino del segmento de carga. No significa que el propio procesador realice ninguna traducción adicional. El cargador AZURE Sphere ELF no usa la dirección física (PhysAddr).

Considere este ejemplo:

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000098 0x00100000 0x00100000 0x00000 0x00e78 RW  0x8
  LOAD           0x0000a0 0x10000000 0x10000000 0x03078 0x03078 RWE 0x10
  LOAD           0x003118 0x00100e78 0x10003078 0x000f0 0x000f0 RW  0x4

El segmento en 0x00100000 está dirigido a memoria estrechamente acoplada (TCM). El cargador copia los datos del paquete de imagen en ram o inicializa el TCM de cero según sea necesario.
El segmento en 0x10000000 se asigna a la ventana XIP para el núcleo. En tiempo de ejecución, los accesos a 0x10000000 + offset se traducen al <address-of-XIP-segment-in-flash> + offset salir del núcleo en tiempo real.
El segmento de datos en la dirección virtual 0x00100e78 se asigna a TCM.

Consideraciones del tiempo de ejecución de ELF

El cargador ELF realiza algunas de las tareas que un binario sin procesar (o cargador de arranque encadenado) realizaría en el arranque. En concreto, inicializa de cero los datos de bloque iniciado por símbolo (BSS) y las copias inicializadas pero mutables datos de flash de solo lectura en RAM, de acuerdo con los encabezados de programa. A continuación, la aplicación se inicia y ejecuta sus propias funciones de inicialización. En la mayoría de los casos, no es necesario realizar cambios en las aplicaciones existentes. La puesta a cero de los datos BSS en la aplicación es innecesario pero inofensivo, porque el cargador ya ha puesto a cero la memoria.

Copiar datos mutables desde flash a RAM puede, en algunas circunstancias, dar lugar a problemas, dependiendo de cómo se resalte el archivo ELF. El cargador ELF procesa los encabezados de programa secuencialmente, sin cambiar el diseño general de los segmentos del archivo. A continuación, asigna no solo el segmento XIP a 0x10000000, sino también los segmentos posteriores en orden. Si los segmentos del archivo ELF están en orden secuencial sin alineación ni espacios, el código de inicio del sistema operativo puede usar un puntero aritmético para buscar el inicio del segmento de datos. Sin embargo, si el archivo ELF tiene un diseño diferente, el puntero aritmético no da como resultado la dirección correcta, por lo que el código de inicio de la aplicación no debe intentar copiar la sección de datos. Esto puede causar problemas si la aplicación o RTOS usa un cargador de arranque encadenado o necesita configurar un stack canary antes de poner a cero BSS o inicializar datos mutables.

Destinos de memoria

Puede destinar código en TCM, flash XIP o SYSRAM editando el script linker.ld para su aplicación. Las aplicaciones de muestra de Azure Sphere se ejecutan desde TCM, pero el archivo de script linker.ld para cada aplicación describe cómo dirigir el flash XIP en su lugar. Como se muestra en el ejemplo siguiente, puede cambiar una muestra para que se ejecute en XIP mediante el alias de CODE_REGION y RODATA_REGION a FLASH en lugar del TCM predeterminado:

REGION_ALIAS("CODE_REGION", FLASH);
REGION_ALIAS("RODATA_REGION", FLASH);

Para determinar si una aplicación compilada se ejecuta desde flash TCM o XIP, utilice arm-none-eabi-readelf.exe, que forma parte del GNU Arm Embedded Toolchain. Ejecútalo en el archivo .out, que se encuentra en el mismo directorio que el paquete de imagen, y especifica la -l marca (L minúscula) para ver dónde se han colocado el código y los datos de solo lectura. El código y los datos de solo lectura que están en la memoria flash se cargan en la dirección 0x10000000; código y datos en TCM se cargan en la región TCM.

En el ejemplo siguiente se muestra una aplicación que se ejecuta desde la memoria flash.

arm-none-eabi-readelf.exe -l UART_RTApp_MT3620_BareMetal.out

Elf file type is EXEC (Executable file)
Entry point 0x10000000
There are 2 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000074 0x00100000 0x00100000 0x00284 0x003c0 RW  0x4
  LOAD           0x000300 0x10000000 0x10000000 0x013b9 0x013b9 R E 0x10

 Section to Segment mapping:
  Segment Sections...
   00     .data .bss
   01     .text .rodata

Ubicación de la tabla vectorial

En los dispositivos ARMv7-M, la tabla vectorial debe alinearse en un límite de potencia de dos que sea de al menos 128 bytes y no menor que el tamaño de la tabla, como se indica en el Manual de referencia de arquitectura ARMv7-M. Cada núcleo de E/S RT del MT3620 admite 100 interrupciones externas. Por lo tanto, incluyendo el puntero de pila y 15 excepciones estándar, la tabla tiene 116 entradas de 4 bytes, para un tamaño total de 464 bytes, que redondea hasta 512 bytes.

Cuando el código se ejecuta desde flash XIP, la tabla vectorial debe colocarse en 0x10000000 y debe alinearse en un límite de 32 bytes dentro del archivo ELF. Cuando el código no se ejecuta desde flash XIP, la tabla se coloca normalmente al principio de TCM0, que es 0x100000. En cualquier caso, para asegurarse de que la dirección virtual de la tabla está correctamente alineada, coloque la tabla vectorial en una sección dedicada y establezca CODE_REGION a la dirección adecuada.

Las muestras MT3620 BareMetal del repositorio Azure Sphere Samples muestran cómo hacerlo. La declaración de la tabla vectorial en main.c establece su section atributo .vector_tableen . Los alias de script del vinculador CODE_REGION al inicio de TCM o XIP, y el atributo ALIGN establece la alineación de la sección de texto dentro del archivo ELF de la siguiente manera:

SECTIONS
{
    .text : ALIGN(32) {
        KEEP(*(.vector_table))
        *(.text)
    } >CODE_REGION
...
}

Consideraciones de latencia y tiempo real

Las RTApps y las aplicaciones de alto nivel solicitan el acceso a la memoria flash, incluso si no se comunican entre sí. Como resultado, las RTApps que se ejecutan desde flash XIP pueden encontrar latencia alta e impredecible. Las escrituras en flash, como durante una actualización, pueden implicar picos de latencia de hasta varios cientos de milisegundos. Dependiendo de los requisitos de la aplicación, puede administrar esto de varias maneras:

Coloque todo el código y los datos en TCM. El código que se ejecuta desde TCM no es vulnerable a la contención de flash.
Divide el código en secciones críticas y no críticas, y ejecuta el código no crítico desde el flash. El código que tiene requisitos en tiempo real, como un temporizador de vigilancia, no debe tener que ejecutarse cuando otro código está accediendo al flash. Los destinos de memoria describen cómo dirigir el flash XIP en lugar de TCM.
Usar la memoria caché. Una aplicación puede usar los 32 KB más bajos de TCM como caché XIP. Este enfoque no proporciona garantías difíciles en tiempo real en caso de pérdida de caché, pero mejora el rendimiento típico sin necesidad de mover todo el código a la RAM. Consulte la "Hoja de datos MT3620 M4" para obtener información sobre la configuración de la memoria caché XIP.

Share via