Vous avez un problème de poule et d'œuf. Pour faire tourner suffisamment de code pour faire des mallocs ou même utiliser du code C, vous avez déjà une mémoire de travail.
Vous devez définir votre problème. Par exemple, s'agit-il d'une vérification de conception ou d'un test de production ? Testez-vous la puce mémoire elle-même ou la carte ? Normalement, vous achetez des puces (mémoire) qui fonctionnent ou qui ont été testées, ou des puces qui ont une qualité définie par le vendeur. Et vos tests sont souvent des tests de production, les points de soudure de fabrication. Les lignes de données, les lignes d'adresse, les lignes de contrôle.
Le problème de l'oeuf et de la poule est que vous voulez faire tourner un logiciel sur le processeur embarqué, ce qui nécessite un code qui s'exécute quelque part, et cela implique de la mémoire (qui pourrait simplement être de la flash et n'en avoir besoin d'aucune ou d'un minimum). La situation idéale est de fonctionner complètement sans rom, en utilisant uniquement les ressources du processeur ou uniquement les ressources de la puce interne et sans ram externe, de sorte que la ram externe puisse être complètement testée. Chaque ligne d'adresse, etc. Sinon, vous devez trouver un système ou déclarer que des morceaux de mémoire ne seront pas testés.
Ou bien une approche en plusieurs étapes, le code de démarrage de la rom peut faire une vérification rapide d'une petite partie de la ram sans l'utiliser pour fonctionner. Ensuite, copier le programme de test principal dans cette petite partie de la mémoire vive et l'exécuter. Puis faire les tests de la mémoire principale avec plus de flexibilité de code. Vous pouvez utiliser le C au lieu de l'assembleur par exemple. Vous pourriez par exemple faire un pré-test, un test super simple, 25% de la mémoire vive, puis copier le test là, tester les 75% restants, puis déplacer le programme vers un autre 25% de la mémoire vive et faire le test lourd sur les premiers 25% qui n'ont pas eu de test complet.
Types de test, vous devez comprendre les défaillances, vous pouvez vouloir tester les joints de soudure en particulier et les traces sur les cartes de circuits imprimés. Vous pouvez avoir des connexions ouvertes et donc faire en sorte que chaque broche ait un un et un zéro, vous pouvez aussi avoir des courts-circuits, que le un et le zéro couvrent, et vous pouvez avoir des "bits amis" où des broches voisines peuvent avoir un court-circuit entre elles et donc vous voulez que chaque paire de signaux soit différente de l'autre.
Souvent, les gens font des tests comme tous les uns, tous les zéros, les 5, les As. Puis des tests en damier où un emplacement de mémoire contient disons des 5 et le suivant des As. Pour les tests de lignes d'adresses, vous devez utiliser des valeurs non puissantes de deux, ou mieux encore, chaque emplacement de mémoire a une valeur différente, par exemple des mots de 32 bits ayant chacun leur propre adresse.
Si vous utilisez un pseudo-aléatoire, quelque chose de répétable comme un lfsr, un passage pour remplir toute la mémoire en utilisant l'aléatoire, réensemencez, revenez en arrière et vérifiez. puis recommencez et remplissez avec des valeurs inversées, réensemencez et vérifiez les valeurs inversées. Vous obtenez les bits d'adresse, chaque ligne de données, mais tous les voisins ne sont pas vérifiés. Réensemencer et recommencer tout cela en déplaçant le motif aléatoire peut couvrir cela. Parfois, il suffit d'utiliser le test aléatoire comme test d'adresse et les traditionnels uns zéros cinq As, 3s, Cs, 6s, 9s, etc.
Pour ce qui est de votre pointeur vers la mémoire à tester, vous ne pouvez pas vous contenter de faire un malloc, vous devez connaître l'adresse physique et vous occuper de la traduction, le cas échéant, de sorte que si/quand il y a un problème, vous communiquez avec des adresses physiques. Vous devez également connaître et contrôler la part de la mémoire. Normalement, j'écrirai des tests basés sur le processeur en C, mais je n'utiliserai aucun appel à la bibliothèque C (comme malloc, printf ou autre).
