Bonjour à tous, voilà j'ai une petite question. Je suis développeur, je fais du soft embarqué sur un oscilloscope. Nous utilisons comme noyaux temps réel VxWorks. Le micro utilisé dans l'appareil est un ppc mpc823. Ma question va venir. Sur VxWorks 5.4 et tornadoo 2.0 nous avons 4 méthodes pour construire notre projet:
 1-VxWork : le soft est chargé par Ethernet directement en ram. C'est le build que nous utilisons pour débuguer. Explication fournit par VxWorks sur ce build(RAM based VxWorks image, linked to RAM_LOW_ADRS. It is loaded into RAM via some external program such as a bootROM. This is the default development image.)
 
2-VxWork_rom : Le soft est d'abort stoké en flash puis au démarrage de l'appareil le code et tous l'appli sous chargé en ram. L'application fonctionne en ram. C'est le build que nous utilisons pour la production. Explication fournit par VxWorks (RAM based image that starts in ROM. The ROM startup code copies the entire image to RAM and then jumps to it. This image generally has a slower startup time, but faster execution time, than vxWorks_romResident)  
 
3- VxWorks_romCompress Comme précédement le soft est stoké en Flash et en plus il est compressé. Au démarrage de l'appareil le code est d'abort décompressé puis chargé en RAM.L'application fonctionne en ram. Explication fournit par VxWorks(Compressed RAM based image that starts in ROM. This image can fit almost twice the code as other ROM images. But it has the slowest boot time, since the image must be uncompressed. The run-time speed is the same as for vxWorks_rom)
 
4- Et enfin quatrième et dernière possibilité: Le soft est stoké en en Flash. Au démarage de l'appareil l'application fonctionne directement en flash. Ce système fonctionne plus lentement mais permet de gagner de la place en RAM.Explication fournit par VxWorks(ROM resident image. The program text remains in ROM, only the data is copied to RAM. This image has the fastest boot time and uses the least amount of RAM, but runs slower on boards with slow ROM access).
 
Nous avons testé et validé les 3 premiers points, nous n'avons eu aucun problème.Maintenant avec le temps qui passe l'application grossie et nous voulons gagner de la place dans la ram. Donc la solution est d'utiliser la solution 4 et la impossible ça marche pas. En fait l'application commence bien à démarrer mais elle se plante au bout d'un moment plus exactement dans le fichier usrCache.c dans la fonction usrCacheEnable() apres l'instructions  cacheEnable (DATA_CACHE). Malgrés de multiple recherche sur le net je n'ai trouvé aucune solution.  
Si quelqu'un a déjà travaillé sur VxWorks et utilisé l'option VxWorks resident peut être pourra t'il me renseigner?
Si quelqu'un a des renseignement sur le fait qu'un mpc823 peut bloquer en utilisant VxWork resident peut 'il m'aider?
A l'aide svp.
help me.  
 

je connais vxWorks que de nom, mais je me faisais la réflexion suivante : usrCacheEnable() c'est pour activer la mise en cache de données (j'imagine) -> opérations d'écriture. Si ton programme est dans une ROM qui est donc en read-only, c'est pas pour ça que ça plante ton truc? Où alors, usrCacheEnable() est assez malin pour activer la mise en cache dasn l'espace RAM et non là où est stocké le programme (ROM)

Oui je pense qu'il est assé intéligent car en fait  la partie du code ou cela plante c'est pas mon code c'est celui de vxworks et c'est leur enchainement de démarrage donc je suppose qu'ils ont prévu le cas.