Comment l'ajout de données à un segment de la mémoire flash peut-il gâcher le minutage d'un programme?

Question

J'ai une application intégrée en temps réel dont le cycle principal tourne à 10 kHz. Il fonctionne sur une TI TMS320C configurée pour démarrer à partir de la mémoire flash. J'ai récemment ajouté un tableau initialisé à un fichier source, et tout d'un coup, le timing est foutu (d'une manière trop complexe pour bien l'expliquer - l'essentiel, une écriture sur port série ne se termine plus à l'heure.)

Les choses qui me déconcertent à ce sujet:

• Je n'accède même pas aux nouvelles données , je déclare simplement un tableau initialisé.
• Cela dépend de la taille. Le problème n'apparaît que si le tableau contient> 40 mots.
• Je sais que je ne déborde pas de segments de données dans la carte de liens.
• Il n'y a pas de cache de données, donc ce n'est pas pour perturber la cohérence du cache.

Des idées sur la simple augmentation de la taille du segment .cinit en flash peuvent affecter le cadencement de votre code?

Informations complémentaires:
J'ai considéré que le code avait peut-être été déplacé, mais il est bien séparé des données. J'ai vérifié à travers la carte mémoire que tous les segments de code ont les mêmes adresses avant et après le bogue. J'ai également vérifié qu'aucun des segments n'est complet. Les seules adresses qui changent sur la carte sont très peu nombreuses dans la section .cinit. Cette section contient les valeurs de données utilisées pour initialiser les variables dans la RAM (comme mon tableau). Il ne devrait jamais être consulté après l’appel de main ().

Answer 1

Après plus d’une journée passée à regarder les traces et à générer un assemblage, je pense que j’ai compris. Le problème de cause fondamentale s'est avéré être un problème de conception qui ne causait des problèmes que si l'ISR qui avait lancé l'écriture sur le port série entrait en collision avec une priorité plus élevée. Il est juste arrivé que le timing vous aide à comprendre qu’il n’a fallu que l’ajout de quelques instructions supplémentaires dans une boucle pour provoquer la collision des deux interruptions.

La question est donc de savoir comment le fait de stocker, mais de ne pas accéder à des données supplémentaires dans la mémoire flash, entraîne l’exécution d’instructions supplémentaires.

Il semble que la réponse soit liée, mais pas tout à fait identique, aux suggestions de Frosty et Frederico. Le nouveau tableau déplace certaines variables existantes, mais pas entre les limites de la page ou vers des régions plus lentes (sur ce forum, les temps d'accès devraient être les mêmes pour toutes les régions). Mais cela modifie les décalages de certaines structures fréquemment utilisées, ce qui oblige l'optimiseur à émettre des séquences d'instructions légèrement différentes pour y accéder. Un alignement de données peut provoquer un arrêt du pipeline à un cycle, contrairement à l'autre. Et ces quelques instructions ont suffisamment décalé le timing pour exposer le problème sous-jacent.

Answer 2

Mes soupçons indiqueraient un changement d’alignement entre vos données / code et le support / mémoire sous-jacent. L'ajout à vos données modifierait l'emplacement de la mémoire dans votre segment de mémoire (selon le modèle de mémoire) et risquerait de placer votre code sur une limite de "pages" sur le périphérique flash, provoquant ainsi une latence qui n'existait pas auparavant.

Answer 3

Peut-être que le nouveau tableau alloué de manière statique pousse les données existantes dans des régions de mémoire plus lentes, ce qui ralentit les accès à ces données?

Answer 4

Le problème se reproduit-il si le tableau est la dernière chose dans son bloc d’espace adresse? Si ce n'est pas le cas, essayez de déplacer la déclaration de tableau de manière à ce que les éléments placés après soient mélangés pour être placés avant. De cette façon, vous pouvez localiser l’objet concerné et commencer à comprendre pourquoi son déplacement est la cause du retard.

Answer 5

Je me risquerais et dirais que vous n’avez pas de problème de performances ici, mais plutôt une sorte de corruption de mémoire qui apparaît comme un problème de performances. Ajouter un tableau à votre exécutable en changeant l'image mémoire. Je suppose donc que vous avez une corruption de mémoire qui est généralement inoffensive (c'est-à-dire que vous écrasez plus de 40 octets et que vous écrasez votre mémoire de plus de 40 octets), la corruption de mémoire aggrave le problème. Laquelle est une vraie question

Answer 6

L'initialisation pourrait-elle écraser un autre morceau de code adjacent? Y a-t-il des structures ou des variables qui utilisent le tableau, qui sont maintenant plus grandes et pourraient causer un stackoverflow?

Answer 7

Peut-être aussi un conflit de banque ou de page. Peut-être avez-vous deux routines appelées assez souvent (des gestionnaires d’interruptions ou autre) qui ont été sur la même page et sont maintenant divisées en deux pages.