Bienvenue aux nouveaux arrivants sur FantasPic !

- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.

--- L’équipe FantasPic ---
Forum général sur l'Assembleur !

Modérateur : mazertoc

soucis avec debugger de PicKit 3
JJE
Passioné
Passioné
Messages : 357
Âge : 79
Enregistré en : novembre 2017
Localisation : Picardie

#1 Message par JJE » dim. 19 mai 2019 18:28

Bonjour à tous,
Je suis sur un programme de test d'un capteur de température Maxim DS1621 qui utilise le bus I2C sur un 16F884.
Une routine se charge de l'initialisation de quelques variables.
En mode pas à pas, cette routine semble fonctionner, on passe sur toutes les instructions sans problème, même en sautant les sous-programmes appelés (step over).
Si je veux aller plus vite et sauter cette routine, ça plante. De même si j'entre dans la routine et lance un exécuter jusqu'au curseur après avoir mis le curseur sur le return, ça plante aussi.
quelqu'un a-t-il l'expérience d'un programme qui a un tel comportement ?

Sans avoir une grande expérience de ce debugger, il me semble plutôt médiocre
Cordialement

JJE

C'est pas parcequ'on n'a rien à dire qu'il faut fermer sa G....e

soucis avec debugger de PicKit 3
Temps-x
Avatar de l’utilisateur
Expert
Expert
Messages : 1375
Enregistré en : juillet 2016
Localisation : Terre

#2 Message par Temps-x » dim. 19 mai 2019 20:15

Bonsoir JJE, et tout le forum,

Tu utilises quoi comme debug, j'ai appris à mes dépends que l'ordinateur à toujours raison, peux tu poster le code.

==> A+
:roll: Les requins, c'est comme le langage ASM, c'est le sommet de la chaîne alimentaire. :wink:

soucis avec debugger de PicKit 3
JJE
Passioné
Passioné
Messages : 357
Âge : 79
Enregistré en : novembre 2017
Localisation : Picardie

#3 Message par JJE » lun. 20 mai 2019 16:10

Bonjour Temps-X, merci de t'intéresser à mes soucis
Temps-x a écrit :Source du message j'ai appris à mes dépends que l'ordinateur à toujours raison
, j'en suis complètement convaincu.
MPLAB propose Debugger/Select tool/Pickit3, c'est celui que j'active après avoir connecté mon PicKit3 (officiel) à ma platine de mise au point. Il a l'air très pauvre :cry:
Pour le code, je t'extrais les lignes pertinentes :

Code : Tout sélectionner

    __CONFIG _CONFIG1, _INTOSCIO & _WDTE_OFF & _PWRTE_OFF & _BOREN_OFF & _LVP_OFF & _DEBUG_ON & _CP_OFF & _CPD_OFF
    __CONFIG _CONFIG2
, _WRT_OFF & _BOR21V

Code : Tout sélectionner

init
    call    ClearRam
    call    InitRegSpec
    DS1621_Init APP_BaudRate
    call    InitVariables

init est le point d'entrée du programme
ClearRam est la routine classique
InitRegSpec initialise les FSR utilisés :
► Afficher le texte

avec les valeurs suivantes
► Afficher le texte

DS1621_Init APP_BaudRate instancie la macro     DS1621_Init  qui règle la vitesse du bus I2C utlisé à APP_BaudRate. En passant, elle initialise FSR (et IRP) pour pointer sur un tampon gérant les données entre le programme principal et le module DS1621.
call    InitVariables
► Afficher le texte

initialise quelques variables du programme principal, en particulier obj_DS1621_1 en calculant l'@ I2C à partir de son "numéro" obj_DS1621_1_VAL câblé sur la platine d'essais. Dans le projet définitif, j'aurai plusieurs DS1621 et une variable associée à chacun qui me permettront de les interroger successivement.
call setBoundaries, c'est cette routine qui pose problème
► Afficher le texte

elle initialise les deux registres du DS1621 utilisés quand on l'utilise en thermostat (TLOWER et TUPPER). en fait ce sont les appels à DS1621_SetLOWER_TEMP et DS1621_SetUPPER_TEMP opérés par la macro CALL_DS1621   pour "l'objet" obj_DS1621_1.
En pas à pas, tout se passe bien, du moins apparemment, même si sur les instanciations de CALL_DS1621, on fait un "step over".
Mais si on s'arrête en début de routine et que l'on pose le curseur sur le return et qu'on demande "run to cursor", le programme plante dans le ssp DS1621_SetLOWER_TEMP ou DS1621_SetUPPER_TEMP.

la macro CALL_DS1621
► Afficher le texte


la routine DS1621_SetLOWER_TEMP
► Afficher le texte


DS1621_WaitNVB attend que le DS1621 autorise l'écriture dans sa mémoire
► Afficher le texte


DS1621_Write_2Bytes envoie 2 octets aux DS1621
► Afficher le texte


DS1621_Write_Byte envoie une trame composée de l'@I2C du périphérique cible, l'@ où écrire dans cette cible, le premier octet de la valeur à écrire. N'émet pas d'acquittement pour pouvoir chaîner l'envoi des octets suivants éventuels.
► Afficher le texte


DS1621_Write_1Byte_1 pour gagner quelques octets utilise la fin du code deWrite_1Byte qui encoie le NonAck et le stop et restaure FSR.
► Afficher le texte


i2c_write envoie un octet sur le bus I2C
► Afficher le texte


IWAIT SSPCON2, ACKSTAT est une instanciation de la macro IWAIT qui attend que le bit ACKSTAT du registre SSPCON2 soit clear
► Afficher le texte


Quand le programme plante et que je l'arrête avec stop, c'est dans la boucle ci-dessus qu'il tourne, il semble ne pas recevoir l'acquittement qu'il attend du DS1621, mais pourquoi le reçoit-il en pas à pas ?
oops et :bravo: si tu m'as lu jusqu'ici.
Cordialement

JJE

C'est pas parcequ'on n'a rien à dire qu'il faut fermer sa G....e


Retourner vers « Langage ASM »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité