IAP Bootloader n'a pas pu charger l'image d'application RTX

Question

Je logiciel découpée en deux: Bootloader (sans RTX), l'image de l'application avec RTX. Mais le bootloader n'a pas pu charger l'image de l'application avec RTX. Les paramètres Flash sont:

 
-------------------------------------------------------------------- 
     start address  size 
IROM 1: 0x08000000   0x2800 - Bootloader (without RTX) 
IROM 2: 0x08002800   0xD000 - Application Image (with RTX) 

J'ai essai 3 façons: (1) Utilisez une autre application sans RTX. Le chargeur de démarrage peut charger l'application avec succès.

(2) Changer l'application avec le réglage projet RTX IROM. Je change l'adresse de début IROM du projet d'application de 0x08002800 à 0x08000000. Et je télécharge l'image de l'application dans le flash à partir de l'adresse 0x08000000. L'image peut fonctionner avec succès à partir de 0x08000000.

(3) L'image de l'application IROM commencer paramètre d'adresse est 0x08002800. Après avoir téléchargé le bootloader et l'image de l'application dans Flash, je débogue le projet de l'application dans Keil, étape par étape. J'ai trouvé qu'il y a une erreur "osTimerthread stack overflow". Ensuite, la pile de threads principale est également débordée. J'ai essayé d'augmenter la taille de la pile, mais cela ne fonctionne pas. J'ai trouvé que l'application démarre dans la commutation du noyau RTX. Tous les threads sont en attente et ne sont pas en cours d'exécution.

Ps, quand je suis dans le débogage Keil, élément d'essai (2) ont également empiler des erreurs de débordement lors de l'initialisation du noyau. L'article (2) fonctionne bien jusqu'à maintenant. Donc, je viens de mettre toute l'information nécessaire ici.

C'est l'image de débogage pour le point (3).

Answer 1

Êtes-vous réellement changer le script de liaison pour relier à partir de 0x08002800 lorsque vous utilisez le bootloader ou juste chargement de l'application (liée à 0x08000000) à un décalage de 0x2800? Vérifiez-le (regardez dans le fichier carte) pour votre sortie liée afin de vous assurer que tous vos symboles ne sont pas liés dans la plage 0x08000000 - 0x08002800.

De plus, assurez-vous que vous utilisez le point d'entrée correct et pointeur de pile. Le pointeur de pile de l'application doit être à 0x08002800 et le vecteur de réinitialisation à 0x08002804. Votre bootloader devra configurer le registre MSP avec le pointeur de pile correct avant de passer à l'application. Voici quelques exemples de code de DFU USB bootloader ST:

typedef void (*pFunction)(void); 
pFunction JumpToApplication; 
uint32_t JumpAddress; 

/* Jump to user application */ 
JumpAddress = *(__IO uint32_t*) (USBD_DFU_APP_DEFAULT_ADD + 4); 
JumpToApplication = (pFunction) JumpAddress; 

/* Initialize user application's Stack Pointer */ 
__set_MSP(*(__IO uint32_t*) USBD_DFU_APP_DEFAULT_ADD); 
JumpToApplication(); 

De plus, selon la quantité de votre bootloader configure avant de sauter à l'application, vous devrez peut-être « Déconfigurer » certains périphériques. Par exemple, si vous configurez vos horloges dans le bootloader avant de décider de passer à l'application, vous risquez de rencontrer des problèmes dans votre application si elle suppose que les horloges sont déjà dans la configuration par défaut. Des choses similaires peuvent se produire avec NVIC et SysTick si votre bootloader les utilise avant de passer à l'application. Enfin, dans le même ordre d'idée que la section précédente, l'application peut émettre des hypothèses sur l'état des périphériques par défaut, mais elle peut également supposer que les paramètres par défaut sont corrects. Par exemple: SCB->VTOR a une valeur par défaut (je crois que c'est toujours 0x00000000), et cela pointe vers la table vectorielle. Votre bootloader sera lié pour avoir sa table de vecteurs à cet endroit. Vous devez vous assurer que lorsque votre application démarre, elle met à jour le registre VTOR pour pointer vers l'emplacement réel de sa table vectorielle.

Espérons que l'une de ces sections vous aide à identifier le problème.