Test du noyau de démarrage

Question

Est-ce que quelqu'un a écrit un plan de test pour une ROM de démarrage?

Cette ROM d'amorçage Il suffit de démarrer le périphérique de flash ou un hôte via SPI

Il sera utilisé dans un système embarqué avec le cortex M3 et l'acquisition de données provenant de capteurs

-vous modifier le code ROM de démarrage pour les tests unitaires/d'intégration?

Merci beaucoup

Answer 1

Oui, plusieurs fois, mais il fonctionne mieux si vous concevez le système dès le départ du sol, pour les tests. Cela signifie la construction d'une maquette avec des connexions aux cartes d'E/S numériques et analogiques dans votre boîte de développement ou de test, si les critères de budget et de conception le permettent. J'ai vu des maquettes qui étaient des tableaux de FPGA et d'autres logiques couvrant un panneau de bus de 8 'par 4' monté au mur dans un laboratoire avec des racks de HPC intégrés (tests de conception ASIC). Bien sûr, vous devez parfois ralentir les choses de plusieurs ordres pour rester dans les limites de votre matériel. Dans votre cas, il suffit simplement de mesurer le temps de démarrage réel de la mise sous tension/réinitialisation du système à chaque fois que le code de démarrage fournit un signal à une broche de test ou un paquet de communication. et configurations périphériques. Pour les tests unitaires/d'intégration, ce POST est souvent plus étendu que ce que vous pourriez expédier avec le produit. Cette dernière implique que l'automatisation est exécutée sur une machine de classe PC/Serveur avec les interfaces de programmation nécessaires pour programmer le (s) périphérique (s) et surveiller tout test d'unité/d'intégration ou de signalisation POST. Si vous avez un code POST de développement et d'expédition séparé, vous devez exécuter les deux dans l'environnement de laboratoire pour chaque génération. Au début de la phase de conception du système, et à travers tous les cycles de développement matériel et logiciel, surveillez les fonctionnalités qui ne peuvent pas être testées dans des simulations et isolez celles de ce qui peut être entièrement simulé. Les cycles de test de votre DevOp doivent exécuter tous les tests de ces parties de la base de code avant d'autoriser les soumissions. Cela comprend le maintien des simulacres nécessaires au fur et à mesure du développement. Il est presque toujours moins onéreux d'exécuter des tests unitaires sur une machine de test PC/Serveur, contre certains simulacres, que de modifier le matériel et de l'intégrer à DevOps, c'est aussi plus rapide dans la plupart des cas.

EDIT: Vous pouvez également intégrer un ou plusieurs Cortex M3 dans un FPGA et implémenter tout votre matériel fantaisie autour de lui comme FPGA logic.