Analyse du fichier CMD pour le Flash API du TMS320F28335

Ce guide décortique le fichier de commande du lieur (.cmd) pour le TMS320F28335, en se concentrant sur la configuration de l'API Flash. Comprendre le mappage mémoire matériel et la manière dont il est représenté dans le fichier .cmd est essentiel pour une gestion correcte du code et des données.

Compréhension de l'architecture mémoire du F28335

Avant d'aborder le fichier .cmd, il est crucial de saisir la disposition physique de la mémoire du F28335. Cette compréhension forme la base de toute configuration de fichier .cmd.

1.1 Catégories de mémoire et mécanisme de pagination (PAGE 0/PAGE 1)

Le F28335 est un DSP basé sur l'architecture Harvard, caractérisée par une séparation de l'adressage de la mémoire programme et de la mémoire de données. Pour s'adapter à cette architecture, TI a introduit un mécanisme de partitionnement logique appelé PAGE 0 et PAGE 1.

PAGE 0 : Principalement utilisée pour la mémoire programme (code, constantes, vecteurs d'interruption, BootROM).
PAGE 1 : Principalement utilisée pour la mémoire de données (variables, pile, registres périphériques, données DMA).

Points clés :

Une adresse mémoire physique ne peut pas être assignée simultanément à PAGE 0 et PAGE 1 pour éviter les conflits.
Le F28335 utilise un adressage mémoire unifié ; PAGE 0 et PAGE 1 sont des partitions logiques utilisées par le lieur et le CPU lors de l'adressage.

1.2 Composition de la mémoire physique (correspondant à la section `MEMORY` du fichier .cmd)

La mémoire physique du F28335 comprend : la RAM interne, la Flash interne, l'OTP, la Boot ROM et l'interface externe (XINTF). La Flash est particulièrement importante car elle est manipulée par le Flash28_API.

1.2.1 RAM interne (lecture/écriture rapide, pour l'exécution de code/stockage de données)

RAMM0/RAMM1 : RAM d'adresse basse, souvent utilisée pour la pile, le mappage des registres périphériques et le stockage de petites quantités de données.
RAML0~RAML7 : RAM d'adresse haute, divisée en 8 blocs (4 Ko chacun), servant de principale RAM utilisateur pour l'exécution de code (PAGE 0) ou le stockage de données (PAGE 1).

Ces RAM offrent un accès rapide avec zéro état d'attente mais perdent leurs données à la mise hors tension.

1.2.2 Flash interne (non volatile, pour le stockage de programmes/constantes)

C'est l'objet principal de l'API Flash. Le F28335 divise sa Flash interne en plusieurs secteurs (ou blocs), chacun avec sa propre plage d'adresses et sa taille, correspondant aux entrées FLASHH~FLASHA dans le fichier .cmd.

Nom du Secteur Flash	Adresse de départ (origin)	Longueur (length)	Taille	Remarques
FLASHH	0x300000	0x008000	32 Ko	Secteur Flash à l'adresse la plus haute
FLASHG	0x308000	0x008000	32 Ko
FLASHF	0x310000	0x008000	32 Ko
FLASHE	0x318000	0x008000	32 Ko
FLASHD	0x320000	0x008000	32 Ko	Couramment utilisé pour `ramfuncs`/Flash API
FLASHC	0x328000	0x008000	32 Ko
FLASHB	0x330000	0x008000	32 Ko
FLASHA	0x338000	0x007F80	~32 Ko	Contient le CSM, les vecteurs de démarrage, etc.

Caractéristiques clés des secteurs Flash :

Granularité d'effacement : La Flash ne peut être effacée que secteur par secteur. L'API Flash comprend des fonctions pour réaliser cet effacement.
Contraintes de programmation : Avant d'écrire des données dans la Flash, le secteur correspondant doit être effacé (son contenu devient 0xFFFF).
Conflit d'exécution : Il est interdit d'exécuter du code depuis un secteur Flash en cours d'effacement ou de programmation. C'est la raison fondamentale pour laquelle le Flash28_API doit être exécuté depuis la RAM.

1.2.3 Autres mémoires (pour information générale)

OTP : Mémoire programmable une seule fois, utilisée pour les clés de chiffrement, les données d'étalonnage.
Boot ROM : Contient le programme de démarrage, les tables mathématiques IQ, les tables FPU ; elle est immuable.
XINTF : Interface pour mémoire externe, permettant l'extension avec de la Flash/RAM externe.

La section MEMORY du fichier .cmd : Cartographie de la mémoire matérielle en blocs logiques

La section MEMORY du fichier .cmd définit simplement les adresses et tailles de la mémoire physique du F28335 en tant que noms logiques reconnus par le lieur (par exemple, FLASHD, RAML0).

2.1 Exemple d'analyse du code principal de la section `MEMORY`


MEMORY
{
PAGE 0:    /* Mémoire Programme : correspond à l'espace programme de l'architecture Harvard */
  RAML0       : origin = 0x008000, length = 0x001000  /* Adresse et taille de la RAML0 physique */
  FLASHD      : origin = 0x320000, length = 0x008000  /* Adresse et taille du FlashD physique */
  FLASHA      : origin = 0x338000, length = 0x007F80  /* Adresse et taille du FlashA physique */
  /* Autres blocs de mémoire programme... */

PAGE 1 :   /* Mémoire Données : correspond à l'espace données de l'architecture Harvard */
  RAMM1       : origin = 0x000400, length = 0x000400  /* Adresse et taille de la RAMM1 physique */
  RAML4       : origin = 0x00C000, length = 0x001000  /* Adresse et taille de la RAML4 physique */
  /* Autres blocs de mémoire données... */
}

origin : L'adresse de départ de la mémoire physique.
length : La taille du bloc mémoire en hexadécimal.
Nom logique : Un alias (ex: RAML0, FLASHD) utilisé par le lieur pour allouer des sections par la suite.

La section SECTIONS : Mappage des segments logiques aux blocs mémoire physiques

La section SECTIONS est aussi fondamentale que MEMORY dans un fichier .cmd. Elle établit la relation entre les segments logiques du programme et les blocs mémoire physiques définis dans MEMORY.

On peut faire une analogie :

Composant	Analogie	Rôle
Section `MEMORY`	Les pièces d'un grand bâtiment	Définit la mémoire physique (secteurs Flash, blocs RAM), avec adresse, taille et partition (PAGE 0/1).
Section `SECTIONS`	Les personnes et objets dans le bâtiment	Définit les segments logiques du programme (code, données, pile, etc.) et spécifie dans quelle pièce ils doivent être placés.

3.1 Deux concepts clés de `SECTIONS`

3.1.1 Segment (Section) : Le "module logique" du programme

Un segment est la plus petite unité logique d'un programme. Il en existe deux types :

Segments par défaut du compilateur : Générés automatiquement par le compilateur C/C++ (ex: .text pour le code, .ebss pour les variables non initialisées, .econst pour les constantes).
Segments définis par l'utilisateur : Créés par le développeur pour regrouper des fonctions ou des données spécifiques (ex: ramfuncs, Flash28_API).

3.1.2 Configuration des propriétés de segment : Clé pour gérer les contraintes matérielles

Le lieur permet de configurer l'adresse de chargement (LOAD) et l'adresse d'exécution (RUN) d'un segment. C'est essentiel pour le F28335.

LOAD (adresse de chargement/stockage) : Emplacement physique du segment lorsque le programme est gravé sur le matériel (généralement dans la Flash, non volatile).
RUN (adresse d'exécution) : Emplacement où le segment est réellement exécuté ou stocké pendant le fonctionnement du programme (généralement dans la RAM, rapide, sans conflit matériel).

Il existe deux modes :

LOAD=RUN (par défaut) : L'adresse de stockage et d'exécution sont identiques. Le segment s'exécute directement depuis son emplacement de stockage (ex: le segment .text stocké dans FLASHA s'exécute depuis FLASHA).
LOAD≠RUN (mode séparé) : Les adresses de stockage et d'exécution diffèrent. Il faut copier manuellement le segment de l'adresse LOAD vers l'adresse RUN avant son exécution. C'est le principe fondamental de ramfuncs et du Flash28_API.

L'API Flash : Quel est son rôle ?

Flash28335_API_V210.lib est une bibliothèque officielle fournie par TI pour manipuler la mémoire Flash interne du F28335. Elle contient des fonctions telles que Flash_Erase(), Flash_Program(), et Flash_Verify(), ainsi que la logique de machine d'état, de gestion des timeouts et de vérification.

Point crucial : Ces fonctions ne doivent absolument pas être exécutées depuis la Flash. Elles doivent impérativement s'exécuter depuis la SARAM (RAM).

Structure générale de l'API Flash dans le fichier .cmd

Examinons la définition typique d'un segment pour l'API Flash :


Flash28_API: {
   -lFlash28335_API_V210.lib(.econst)
   -lFlash28335_API_V210.lib(.text)
} LOAD = FLASHD, RUN = RAML0, LOAD_START(_Flash28_API_LoadStart), LOAD_END(_Flash28_API_LoadEnd), RUN_START(_Flash28_API_RunStart), PAGE = 0

5.1 `Flash28_API:` - Définition du nom du segment

Ceci définit un nom de segment logique dans le lieur. Ce n'est ni une variable C, ni une fonction, mais un conteneur logique pour regrouper des parties spécifiques d'une bibliothèque.

5.2 Le contenu entre accolades `{ }`

-lFlash28335_API_V210.lib : Indique au lieur d'inclure la bibliothèque spécifiée. L'équivalent de l'ajout de cette bibliothèque dans les paramètres de liaison du projet CCS.
(.text) : Représente le code machine des fonctions de l'API Flash.
(.econst) : Représente les constantes utilisées par l'API Flash, y compris les tables de consultation. TI inclut ces constantes pour assurer l'intégrité de l'API.
*(.text) vs (.text) : L'utilisation de (.text) au lieu de *(.text) permet de sélectionner uniquement le code de l'API Flash, évitant ainsi d'inclure accidentellement le code utilisateur. C'est une extraction ciblée.

5.3 `LOAD = FLASHD` - Où le code est stocké après la compilation

Indique que, après la liaison, le segment Flash28_API résidera dans le secteur FLASHD. C'est l'emplacement initial où le code de l'API sera gravé dans la mémoire Flash.

5.4 `RUN = RAML0` - Où le code est réellement exécuté

Spécifie que le CPU lira et exécutera le code de l'API Flash depuis RAML0. L'API Flash ne s'exécute jamais depuis la Flash elle-même. RAML0 est choisi pour sa vitesse (zéro état d'attente) et sa proximité avec la Flash.

5.5 `LOAD_START`, `LOAD_END`, `RUN_START`

Ces symboles sont générés par le lieur et sont utilisés par le code C pour gérer la copie du segment de la Flash (adresse LOAD) vers la RAM (adresse RUN). Le code C utilise généralement memcpy avec ces symboles pour effectuer ce "déménagement" avant l'exécution.

_Flash28_API_LoadStart : Adresse de début du segment dans la Flash.
_Flash28_API_LoadEnd : Adresse de fin du segment dans la Flash.
_Flash28_API_RunStart : Adresse de début du segment dans la RAM.

5.6 `PAGE = 0` - Déclaration de l'espace mémoire

Indique que ce segment appartient à l'espace programme (PAGE 0). Même s'il est exécuté depuis la RAM, il est considéré comme faisant partie de l'espace programme car il s'agit de code exécutable.

Le segment ramfuncs

Le segment ramfuncs a une fonction très similaire à celle de Flash28_API. La principale différence est que Flash28_API est spécifique à la bibliothèque officielle de TI, tandis que ramfuncs est généralement utilisé par le développeur pour définir des fonctions utilisateur qui doivent être exécutées depuis la RAM pour des raisons de performance ou pour éviter les conflits lors des opérations Flash.

Sa configuration est typiquement la même :


ramfuncs LOAD = FLASHD, RUN = RAML0, LOAD_START(_RamfuncsLoadStart), LOAD_END(_RamfuncsLoadEnd), RUN_START(_RamfuncsRunStart), PAGE = 0

Dans l'esprit du lieur, Flash28_API et ramfuncs sont des entités similaires : stockées en Flash, exécutées en RAM.

Pourquoi isoler l'API Flash dans son propre segment ?

Si l'API Flash était mélangée avec le code principal (par exemple, dans le segment .text) et que ce dernier était situé dans un secteur Flash utilisé pour l'exécution (comme FLASHA), cela entraînerait des problèmes graves.

Lors d'une opération d'effacement d'un autre secteur Flash, si le CPU tentait d'exécuter le code de l'API Flash (situé dans ce même secteur), cela provoquerait une erreur système (bus error) ou un comportement erratique. TI impose donc cette séparation pour garantir la stabilité.

Relation entre l'API Flash, les 8 secteurs et le projet

Dans un projet typique utilisant le F28335, les secteurs Flash sont souvent utilisés comme suit :

FLASHA : Programme principal, vecteurs de démarrage.
FLASHD : Zone de chargement pour l'API Flash et les fonctions ramfuncs.
FLASHC : Bibliothèques mathématiques (IQmath).
FLASHB / E / F / G / H : Données utilisateur non volatiles.

Récapitulatif des symboles du fichier .cmd

Voici un tableau de référence rapide pour les symboles couramment rencontrés dans la configuration de l'API Flash :

Symbole	Signification
`NomSegment:`	Définit un nom de segment logique.
`{ ... }`	Contient les objets à placer dans le segment.
`-lxxx.lib`	Lie une bibliothèque spécifique.
`(.text)`	Code machine des fonctions.
`(.econst)`	Constantes et tables utilisées par les fonctions.
`LOAD =`	Adresse de stockage physique (après la compilation/liaison).
`RUN =`	Adresse d'exécution réelle (pendant le fonctionnement).
`LOAD_START()`	Pointeur vers l'adresse de début du segment dans la mémoire `LOAD`.
`LOAD_END()`	Pointeur vers l'adresse de fin du segment dans la mémoire `LOAD`.
`RUN_START()`	Pointeur vers l'adresse de début du segment dans la mémoire `RUN`.
`PAGE = 0`	Indique que le segment appartient à l'espace mémoire programme.

Analyse de sections spécifiques courantes

.cinit : > FLASHA PAGE=0 : Contient les données d'initialisation des variables C. Ces données sont stockées dans la Flash (FLASHA) et copiées en RAM au démarrage. PAGE=0 car c'est de la mémoire programme (initialisation).
.pinit : > FLASHA, PAGE=0 : Contient les tables d'initialisation pour les objets C++. Stocké en FLASHA, PAGE=0.
.text : > FLASHA PAGE=0 : Le segment principal du code programme utilisateur. Stocké en FLASHA et exécuté depuis la Flash (LOAD=RUN). PAGE=0 car c'est de l'espace programme.
codestart : > BEGIN PAGE=0 : Définit le point d'entrée du programme. Situé dans une petite zone spécifique (BEGIN) de la Flash pour le démarrage. PAGE=0.
ramfuncs LOAD = FLASHD RUN = RAML0 ... PAGE=0 : Comme mentionné précédemment, ce segment stocke des fonctions utilisateur en FLASHD pour les exécuter depuis RAML0. PAGE=0 car ce sont des fonctions exécutables.
.stack : > RAMM1 PAGE=1 : Définit la zone de pile (stack) dans la RAM RAMM1. PAGE=1 car c'est de la mémoire de données.
.ebss : > RAML4 PAGE=1 : Segment pour les variables globales et statiques non initialisées. Situé dans RAML4, PAGE=1.
.econst : > FLASHA PAGE=0 : Segment pour les données constantes (ex: chaînes de caractères, tables) qui doivent être stockées en mémoire non volatile. Situé dans FLASHA, PAGE=0.
IQmath : > FLASHC PAGE=0 : Code pour les fonctions mathématiques IQ. Situé dans FLASHC, PAGE=0.
IQmathTables : > IQTABLES, PAGE=0, TYPE=NOLOAD : Tables pour les fonctions IQ math. NOLOAD signifie que ces données ne sont pas chargées dans le fichier exécutable car elles sont pré-programmées dans la Boot ROM. PAGE=0.
.reset : > RESET, PAGE=0, TYPE=DSECT : Section spéciale utilisée pour la liaison, souvent marquée comme DSECT (segment discardé) car le démarrage depuis la Boot ROM n'utilise pas ces informations de la même manière.
vectors : > VECTORS PAGE=0, TYPE=DSECT : Table des vecteurs d'interruption. Peut être DSECT si le démarrage se fait via la Boot ROM.
.adc_cal : load = ADC_CAL, PAGE=0, TYPE=NOLOAD : Fonction d'étalonnage ADC pré-programmée par le fabricant dans une zone réservée. NOLOAD car elle est déjà présente.

Ce fichier .cmd, en particulier les sections MEMORY et SECTIONS, est le pont essentiel entre le matériel du F28335 et la manière dont votre code est organisé et exécuté.

Exemple de fichier .cmd complet :


/*
//###########################################################################
//
// FILE:	F28335.cmd
//
// TITLE:	Linker Command File For F28335 Device
//
//###########################################################################
// $TI Release: F28335 API Release V2.10 $
// $Release Date: August 18, 2008 $
//###########################################################################
*/

/* ======================================================
// For Code Composer Studio V2.2 and later
// ---------------------------------------
// In addition to this memory linker command file,
// add the header linker command file directly to the project.
// The header linker command file is required to link the
// peripheral structures to the proper locations within
// the memory map.
//
// The header linker files are found in <base></base>\DSP2833x_Headers\cmd
//
// For BIOS applications add:      DSP2833x_Headers_BIOS.cmd
// For nonBIOS applications add:   DSP2833x_Headers_nonBIOS.cmd
========================================================= */

/* ======================================================
// For Code Composer Studio prior to V2.2
// --------------------------------------
// 1) Use one of the following -l statements to include the
// header linker command file in the project. The header linker
// file is required to link the peripheral structures to the proper
// locations within the memory map                                    */

/* Uncomment this line to include file only for non-BIOS applications */
/* -l DSP2833x_Headers_nonBIOS.cmd */

/* Uncomment this line to include file only for BIOS applications */
/* -l DSP2833x_Headers_BIOS.cmd */

/* 2) In your project add the path to <base></base>\DSP2833x_headers\cmd to the
  library search path under project->build options, linker tab,
  library search path (-i).
/*========================================================= */

/* Define the memory block start/length for the F28335
  PAGE 0 will be used to organize program sections
  PAGE 1 will be used to organize data sections

   Notes:
         Memory blocks on F28335 are uniform (ie same
         physical memory) in both PAGE 0 and PAGE 1.
         That is the same memory region should not be
         defined for both PAGE 0 and PAGE 1.
         Doing so will result in corruption of program
         and/or data.

         L0/L1/L2 and L3 memory blocks are mirrored - that is
         they can be accessed in high memory or low memory.
         For simplicity only one instance is used in this
         linker file.

         Contiguous SARAM memory blocks can be combined
         if required to create a larger memory block.
*/


MEMORY
{
PAGE 0:    /* Program Memory */
          /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */

  ZONE0       : origin = 0x004000, length = 0x001000     /* XINTF zone 0 */
  RAML0       : origin = 0x008000, length = 0x001000     /* on-chip RAM block L0 */
  RAML1       : origin = 0x009000, length = 0x001000     /* on-chip RAM block L1 */
  RAML2       : origin = 0x00A000, length = 0x001000     /* on-chip RAM block L2 */
  RAML3       : origin = 0x00B000, length = 0x001000     /* on-chip RAM block L3 */
  ZONE6       : origin = 0x0100000, length = 0x100000    /* XINTF zone 6 */
  ZONE7A      : origin = 0x0200000, length = 0x00FC00    /* XINTF zone 7 - program space */
  FLASHH      : origin = 0x300000, length = 0x008000     /* on-chip FLASH */
  FLASHG      : origin = 0x308000, length = 0x008000     /* on-chip FLASH */
  FLASHF      : origin = 0x310000, length = 0x008000     /* on-chip FLASH */
  FLASHE      : origin = 0x318000, length = 0x008000     /* on-chip FLASH */
  FLASHD      : origin = 0x320000, length = 0x008000     /* on-chip FLASH */
  FLASHC      : origin = 0x328000, length = 0x008000     /* on-chip FLASH */
  FLASHA      : origin = 0x338000, length = 0x007F80     /* on-chip FLASH */
  CSM_RSVD    : origin = 0x33FF80, length = 0x000076     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */
  BEGIN       : origin = 0x33FFF6, length = 0x000002     /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */
  CSM_PWL     : origin = 0x33FFF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA */
  OTP         : origin = 0x380400, length = 0x000400     /* on-chip OTP */
  ADC_CAL     : origin = 0x380080, length = 0x000009     /* ADC_cal function in Reserved memory */

  IQTABLES    : origin = 0x3FE000, length = 0x000b50     /* IQ Math Tables in Boot ROM */
  IQTABLES2   : origin = 0x3FEB50, length = 0x00008c     /* IQ Math Tables in Boot ROM */
  FPUTABLES   : origin = 0x3FEBDC, length = 0x0006A0     /* FPU Tables in Boot ROM */
  ROM         : origin = 0x3FF27C, length = 0x000D44     /* Boot ROM */
  RESET       : origin = 0x3FFFC0, length = 0x000002     /* part of boot ROM  */
  VECTORS     : origin = 0x3FFFC2, length = 0x00003E     /* part of boot ROM  */

PAGE 1 :   /* Data Memory */
          /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE0 for program allocation */
          /* Registers remain on PAGE1                                                  */

  BOOT_RSVD   : origin = 0x000000, length = 0x000050     /* Part of M0, BOOT rom will use this for stack */
  RAMM0       : origin = 0x000050, length = 0x0003B0     /* on-chip RAM block M0 */
  RAMM1       : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */
  RAML4       : origin = 0x00C000, length = 0x001000     /* on-chip RAM block L1 */
  RAML5       : origin = 0x00D000, length = 0x001000     /* on-chip RAM block L1 */
  RAML6       : origin = 0x00E000, length = 0x001000     /* on-chip RAM block L1 */
  RAML7       : origin = 0x00F000, length = 0x001000     /* on-chip RAM block L1 */
  ZONE7B      : origin = 0x20FC00, length = 0x000400     /* XINTF zone 7 - data space */
  FLASHB      : origin = 0x330000, length = 0x008000     /* on-chip FLASH */
}

/* Allocate sections to memory blocks.
  Note:
        codestart user defined section in DSP28_CodeStartBranch.asm used to redirect code
                  execution when booting to flash
        ramfuncs  user defined section to store functions that will be copied from Flash into RAM
*/

SECTIONS
{

  /* Allocate program areas: */
  /* The Flash API functions can be grouped together as shown below.
     The defined symbols _Flash28_API_LoadStart, _Flash28_API_LoadEnd
     and _Flash28_API_RunStart are used to copy the API functions out
     of flash memory and into SARAM */

  Flash28_API:
  {
       -lFlash28335_API_V210.lib(.econst)
       -lFlash28335_API_V210.lib(.text)
  }                   LOAD = FLASHD,
                      RUN = RAML0,
                      LOAD_START(_Flash28_API_LoadStart),
                      LOAD_END(_Flash28_API_LoadEnd),
                      RUN_START(_Flash28_API_RunStart),
                      PAGE = 0
  .cinit              : > FLASHA      PAGE = 0
  .pinit              : > FLASHA,     PAGE = 0
  .text               : > FLASHA      PAGE = 0
  codestart           : > BEGIN       PAGE = 0
  ramfuncs            : LOAD = FLASHD,
                        RUN = RAML0,
                        LOAD_START(_RamfuncsLoadStart),
                        LOAD_END(_RamfuncsLoadEnd),
                        RUN_START(_RamfuncsRunStart),
                        PAGE = 0

  csmpasswds          : > CSM_PWL     PAGE = 0
  csm_rsvd            : > CSM_RSVD    PAGE = 0

  /* Allocate uninitalized data sections: */
  .stack              : > RAMM1       PAGE = 1
  .ebss               : > RAML4       PAGE = 1
  .esysmem            : > RAMM1       PAGE = 1

  /* Initalized sections go in Flash */
  /* For SDFlash to program these, they must be allocated to page 0 */
  .econst             : > FLASHA      PAGE = 0
  .switch             : > FLASHA      PAGE = 0

  /* Allocate IQ math areas: */
  IQmath              : > FLASHC      PAGE = 0                  /* Math Code */
  IQmathTables     : > IQTABLES,  PAGE = 0, TYPE = NOLOAD
  IQmathTables2    : > IQTABLES2, PAGE = 0, TYPE = NOLOAD
  FPUmathTables    : > FPUTABLES, PAGE = 0, TYPE = NOLOAD

  /* Allocate DMA-accessible RAM sections: */
  DMARAML4         : > RAML4,     PAGE = 1
  DMARAML5         : > RAML5,     PAGE = 1
  DMARAML6         : > RAML6,     PAGE = 1
  DMARAML7         : > RAML7,     PAGE = 1

  /* Allocate 0x400 of XINTF Zone 7 to storing data */
  ZONE7DATA        : > ZONE7B,    PAGE = 1

  /* .reset is a standard section used by the compiler.  It contains the */
  /* the address of the start of _c_int00 for C Code.   /*
  /* When using the boot ROM this section and the CPU vector */
  /* table is not needed.  Thus the default type is set here to  */
  /* DSECT  */
  .reset              : > RESET,      PAGE = 0, TYPE = DSECT
  vectors             : > VECTORS     PAGE = 0, TYPE = DSECT

  /* Allocate ADC_cal function (pre-programmed by factory into TI reserved memory) */
  .adc_cal     : load = ADC_CAL,   PAGE = 0, TYPE = NOLOAD

}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

Étiquettes: TMS320F28335 DSP TI Fichier CMD Lieur

Publié le 9 juin à 16h10

L'Atelier Monstre

Analyse du fichier CMD pour le Flash API du TMS320F28335

1.1 Catégories de mémoire et mécanisme de pagination (PAGE 0/PAGE 1)

1.2 Composition de la mémoire physique (correspondant à la section `MEMORY` du fichier .cmd)

1.2.1 RAM interne (lecture/écriture rapide, pour l'exécution de code/stockage de données)

1.2.2 Flash interne (non volatile, pour le stockage de programmes/constantes)

1.2.3 Autres mémoires (pour information générale)

2.1 Exemple d'analyse du code principal de la section `MEMORY`

3.1 Deux concepts clés de `SECTIONS`

3.1.1 Segment (Section) : Le "module logique" du programme

3.1.2 Configuration des propriétés de segment : Clé pour gérer les contraintes matérielles

5.1 `Flash28_API:` - Définition du nom du segment

5.2 Le contenu entre accolades `{ }`

5.3 `LOAD = FLASHD` - Où le code est stocké après la compilation

5.4 `RUN = RAML0` - Où le code est réellement exécuté

5.5 `LOAD_START`, `LOAD_END`, `RUN_START`

5.6 `PAGE = 0` - Déclaration de l'espace mémoire

Exemple de fichier .cmd complet :

Étiquettes Populaires

L'Atelier Monstre

Analyse du fichier CMD pour le Flash API du TMS320F28335

1.1 Catégories de mémoire et mécanisme de pagination (PAGE 0/PAGE 1)

1.2 Composition de la mémoire physique (correspondant à la section MEMORY du fichier .cmd)

1.2.1 RAM interne (lecture/écriture rapide, pour l'exécution de code/stockage de données)

1.2.2 Flash interne (non volatile, pour le stockage de programmes/constantes)

1.2.3 Autres mémoires (pour information générale)

2.1 Exemple d'analyse du code principal de la section MEMORY

3.1 Deux concepts clés de SECTIONS

3.1.1 Segment (Section) : Le "module logique" du programme

3.1.2 Configuration des propriétés de segment : Clé pour gérer les contraintes matérielles

5.1 Flash28_API: - Définition du nom du segment

5.2 Le contenu entre accolades { }

5.3 LOAD = FLASHD - Où le code est stocké après la compilation

5.4 RUN = RAML0 - Où le code est réellement exécuté

5.5 LOAD_START, LOAD_END, RUN_START

5.6 PAGE = 0 - Déclaration de l'espace mémoire

Exemple de fichier .cmd complet :

Étiquettes Populaires

1.2 Composition de la mémoire physique (correspondant à la section `MEMORY` du fichier .cmd)

2.1 Exemple d'analyse du code principal de la section `MEMORY`

3.1 Deux concepts clés de `SECTIONS`

5.1 `Flash28_API:` - Définition du nom du segment

5.2 Le contenu entre accolades `{ }`

5.3 `LOAD = FLASHD` - Où le code est stocké après la compilation

5.4 `RUN = RAML0` - Où le code est réellement exécuté

5.5 `LOAD_START`, `LOAD_END`, `RUN_START`

5.6 `PAGE = 0` - Déclaration de l'espace mémoire