MPLAB.X ! je deviens fou....

[schneiderj]

Je pense que ce message est destinné à RISC .

Mais tout commentaire par rapport à MPLAB.X (ou MPLAB) sont les bienvenues.

Depuis Noël, je suis en train de terminer le développement de mon projet avec le PIC32. Il y a 2 semaines j'avais des données curieuses lors du déboggage pour certaines variables dans la fenétre watch. A l'époque j'ai perdu, disons une petite dizaine d'heures de travail à la recherche d'un bug que je n'ai pas trouvé. Puis tout est rentré dans l'ordre.

Sauf que depuis le début de la semaine, redite avec MPLAB.X V1.6 nouvellement installé. Re plusieurs heures de perdus . Retour à la version 1.5, tout rentre dans l'ordre à nouveau.
Sauf que mon programme qui est pratiquement terminé plante systématiquement avec une belle erreur générale. Avec REAL ICE j’essaie de suivre le déroulement du programme avec une variable globale en "real time watch".
Et bien rien du tout : après ajout de cette variable (menu watch, ajout d'une nouvelle variable temps réel), le menu watch est vidé... plus une seule variable de présente.

Bref, je contourne ce nouveau problème et fini par localiser le moment ou survient mon erreur générale. Afin de suivre ce qui se passe je place un breakpoint dans la fonction interupt de l'UART concerné. Et voici une capture de l'écran juste avant que je ne sorte de cette fonction. La variable Rx_Buffer est sensé contenir la phrase suivante " OK : LECTURE = 000.002" plus le caractère 0x0D. Et que voit-on ? Rien le buffer est vide !
La capture :
Fonction Interupt.jpg

Un breakpoint plus loin, à l'endroit où je lis ce buffer, je contrôle le contenu de ce buffer : contient-il "OK" si oui exécuter le code contenu dans l’exécution conditionnelle. Voici une nouvelle capture d'écran :
fonction mlecture.jpg

Le buffer affiché dans la fenêtre watch est toujours vide, mais le fait que le curseur soit passé au niveau du code qui n'est exécuté que si le buffer contient "OK" montre que cela n'est pas le cas.

Bref, je peste, je rale et j'ai envie de tout envoyer en l'air.
Qu'est-ce que je dois faire ? Revenir à MPLAB ?

Jean-Marie
-----

[Jack]

C'est peut-être la fenêtre watch qui provoque cet effet car pour afficher le contenu du buffer, celui-ci doit être lu par le debugger. Du coup ton programme n'y trouve plus rien à lire, lui.

A+

[RISC]

Salut,

Tu mentionnes que tu as une erreur générale. Je suppose que ton programme s'arrête tout seul (ce qui correspond à une exception pour le PIC32 = reset).
La méthode la plus puissante pour découvrir la cause d'un RESET sur le PIC32 est d'utiliser les registres du coprocesseur CP0 car ils contiennent des informations permettant de remonter à la cause.
Pour cela, il est recommandé d'utiliser un handler d'exceptions. C'est une méthode qui devrait d'ailleurs être appliqué à CHAQUE PROGRAMME car cela garantit 2 choses :
* la conception de produits robustes qui survivent à tous les reset et blocages
* la mise au point accélérée par identification rapide des sources des PB.

Dans les PIC32 (comme les autres PICs) il y a une multitude de mécanismes pour détecter les erreurs "système" :
* accès à une adresse en dehors de la FLASH
* accès à une adresse en dehors de la RAM
* Watchdog
* Brown Out Reset
* défaut sur l'oscillateur externe
* division par zéro
...
Tu trouveras un exemple d'exception handler ici.

Pour ce qui est du Real-Time watch il faut faire attention à plusieurs choses :
1/ le nombre de variables visualisables simultanément est = aux nombre de breakpoint hardware - 1 . donc dans ton cas 4 ou 5
2/ on ne peut visualiser que des variables ayant la taille du bus (unsigned int = 32 bits pour les PIC32)
3/ on ne peut visualiser que les variables globales
4/ il faut définir la vitesse à laquelle travaille le proceseur dans MPLAB X
5/ il faut aussi ajuster la vitesse de rafraichissement des variables

Il ne faut pas mettre en watch "normal" certains registres particuliers car cela altère le comportement du programme...
Exemple : si on mets RTCVAL, lors de l'arrêt le Real-ice lit la valeur ce qui entraine une auto décrémentation du pointeur et "fausse" la suite du programme.

Dans ton cas la trace sélective peut peut être aider

Ne pas oublier le WIKI de MPLAB X qui permet de mettre en oeuvre certaines fonctions pointues de MPLAB X et du real-ice.

a+

PS : je suis sous MPLAB X v1.60 et j'ai fait du real-time watch sur le PIC24FJ128GA010 cette semaine ;=)

[schneiderj]

Mercdi pour vos réponses.

Je rentre d'un tour de vélo : cela fait du bien même si le temps est loin d'être idéale.

J'ai une fonction qui gére les exeptions :

void _general_exception_handler(void) {
    asm volatile("mfc0 %0,$13" : "=r" (_excep_code));
    asm volatile("mfc0 %0,$14" : "=r" (_excep_addr));

    _excep_code = (_excep_code & 0x0000007C) >> 2;

    return;
    while (1) {
        // Examine _excep_code to identify the type of exception
        // Examine _excep_addr to find the address that caused the exception
    }
}

Et depuis que je l'utilise (grâce à tes conseils) j'évite de tourner en rond dans pas mal de cas.
Mais aujourd'hui mon problème n'est pas cette exception mais le fait que la fenètre watch ne me permet pas de connaitre l'état de mes variables (voire les images jointes : quand un tableau est donné comme étant vide alors que cela n'est pas le cas, il est diffi cle de savoir ce qui se passe).

Bon je file prendre une douche et je retourne sous MPLAB (sans le X). En attendant de comprendre pourquoi j'ai ces variables qui restent nulles.

Et je vais relire vos messages en y passant plus de temps !

Jean-Marie

[A voir en vidéo sur Futura]

[schneiderj]

EDIT post précedant :

d’ailleurs j'aimerais pouvoir avoir en permanence un breakpoint dans la fonction _general_exception_handler(voi d) . Est-il possible d’attribuer un breakpoint qui ne soit pas effaçable depuis la fenêtre breakpoint (lorsque l'on fait "delete all") ?

[schneiderj]

Re...

une douche, un kaki et une discussion avec ma femme plus tard. Je change le driver de REAL ICE pour aller avec MPLAB, puis une petite bagarre pour que mon code soit compilé dans l’environnement MPLAB. Je lance l'application :

1. première constatation : je n'ai pas de problème pour afficher mes variables dans la fenêtre watch
2. seconde constatation : l'erreur est localisé (une erreur de copie de pointeur)

Le problème est réglé, enfin ce bug.

Jean-Marie

[RISC]

Salut,
[QUOTE=schneiderj;4340000]

d’ailleurs j'aimerais pouvoir avoir en permanence un breakpoint dans la fonction _general_exception_handler(voi d) . Est-il possible d’attribuer un breakpoint qui ne soit pas effaçable depuis la fenêtre breakpoint (lorsque l'on fait "delete all") ?

"Delete all" cela fait..."delete all" ;=) comme son nom l'indique.
Si tu veux savoir quand tu vas dans cette fonction de gestion du handler d'exceptions, tu mets tout simplement un Reset() ou reset en asm.
Comme de toute façon tu ne devrais jamais y aller le programme s'arrètera .

Pour ce qui concerne ton tableau (watch window), il m'est impossible de savoir ce qui se passe...
Si tu utilises un petit programme simple, est-ce que tu vois correctement les variables globales quand tu t'arrêtes ?

Compares avec ce que tu vois dans le menu Windows > PIC Memory views > data memory.

En général, si tu as une liaison série en rab, sers-toi s'en pour envoyer sur une console des valeurs

a+

[schneiderj]

Bonsoir,

le phénomène mentionné si dessus à disparu, revenu... mais je peux travailler correctement depuis la fin de la semaine dernière. Normal, je n'ai pratiquement rien fait !!

Ce soir j'ai un nouveau problème et toujours avec MPLAB.X... avec MPLAB, pas de problème.

J'ai travaillé pendant deux heures sans problème avec MPLAB.X, puis j'ai eu ce message après programmation (le programme fonctionne ) :

Target detected
Device ID Revision = 0x34300053

The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x5c7ff
boot config memory
configuration memory

Programming...
Programming/Verify complete

Running
Target Halted
An Error occurred while running

ou :

Programming...
Programming/Verify complete

Running
Target Halted
An Error occurred while running
Invalid command response (sent 0x71, received 0x3f)
Failed getting PC

Je déconnecte, reconnecte, recharge le firmware de REAL ICE. Pas de changement. Avec MPLAB fonctionnement normal.

Je prends mon portable : le programme fonctionne en mode debug avec MPLAB.X (V 1.51, sur le fixe j'ai la version 1.50).

Est-ce mon port USB qui aurait un problème ? Changement de port USB : je passe sur un port situé à l’arrière. J'ai toujours droit aux mêmes erreurs.

Je vais tenter la version 1.6, mais punaise je vois rouge !

Jean-Marie

[schneiderj]

Même comportement avec la version MPLAB.X 1.6.

[schneiderj]

Il semblerait que le problème relaté au début de ce message soit plus ou moins connu par Microchip. Enfin c'est comme cela que j’interprète la dernière réponse que j'ai reçu sur leur forum.

Jean-Marie