Bonjour, je rencontre un petit problème avec un PIC18F. Je programme sur MikroC. A un moment je rentre dans une boucle for avec des interruptions. Le souci c'est que cela marche une fois sur 2. Enfin, au premier démarage du système cela ne marche pas, quand je l'éteind et que je le rallume immédiatement, là cela fonctionne. Je ne sais pas d'où cela peu venir?? Avez-vous des idées??
hello !
gloups ... un peu confu tout ça ... des interruptions dans un for ?
peux-tu nous montrer ton code ? et décrire un peu plus clairement ce que tu veux que ton pic fasse ?
Le code n'aidera pas beaucoup, je me voit mal mettre mon code car il fait appel un une succession de sous programme, se sera donc pas très explicite. Sinon j'essaye de voir sur les histoire de priorités dans les interruptions, en fouillant un peu j'ai chopé comme info que mon compilateur ne gérait les interruption des PIC18 que si elles sont prioritaires, donc je ne sais pas si ça a voir avec ça??? c'est quand même étrange qu'un bref reset après un démarrage corrige mes problèmes???
je ne connais pas mikroC, ses subtilités, ce dont il est capable, etc. mais ce que je sais, effectivement, c'est que la gestion des priorité est primordiale dans les 18F.j'ai chopé comme info que mon compilateur ne gérait les interruption des PIC18 que si elles sont prioritaires
Pour le reset ... as-tu un schéma du circuit, alors ? Ya-til de l'electronique analogique autour de ton pic, avec des temps de mise en place ? (des charges de condo ...) qui font que la premiere fois que tu allume, ton pic demarre avant que l'analogique soit prête, puis après un bref reset, l'analogique est toujours prête (temps de décharge...) du coup le pic démarre dans les bonnes conditions ? j'en sais rien, je suppute, j'ai rien d'autre a me mettre sous la dent que la descritption de ton problème.
au niveau du code :
Fais-tu des sauvegarde dans l'EEPROM ? est-ce que ton programme y fait appel d'une façon ou d'une autre qui pourrait provoquer un plantage du code la premiere fois (parce que vide), et pas la deuxième fois (parce qu'il y eu qqchose d'écrit la premiere fois?)
Un phénomène n'est jamais aléatoire, si ton schéma est propre et ton code aussi. Par expérience, cela vient souvent des périphériques autour du pic. Essaye le code bout par bout, simplifie le au maximum ... (je suis vague, mais je ne peux pas etre plus précis, désolé)
Merci pour ton aide précieuse, je soupçonne effectivement un problème avec l'électronique analogique. Existe-il un moyen simple de faire un reset du PIC de manière software? cela me permettrait de voir si cela vient de là...
Ce qui est étrange c'est que tout les sous programmes que j'ais avant se déroulent sans problème et hop quand j'arrive à ce bout de code ça plante (probleme résolu quand je redémarre):
Code:void CNA_START (){ T=T/128; Av = Av*2; Av2 = Av/1000; delay_ms(50); for (j2 = 0; j2 < cycle; j2++) { for (j = 0; j < 128; j++) { CNA_Output(Av2*sinus[j]); //sortie CNA SPI //lcd_nbr(2,6,sinus[j]," ",1); lcd_nbr(dat_t1,val_pt1,0,5); for (delta=0;delta<T;delta++){ //Tempo Variable for(nbr_mesure=0;nbr_mesure<69;nbr_mesure++){ mespt2(); //acquisition voie 2 avec interruption sur INT1 mespt1(); //acquisition voie 1 avec interruption sur INT0 } } } //buzz(); } }
Non, pas à ma connaissance, mais tu peux faire un reset du PIC uniquement en amenant brièvement (et avec précaution) une masse sur le MCLR du pic.Envoyé par Pilou81
Dans ton code, rien ne me choque à priori ...
Ton CNA est-il bien configuré, peut-il recevoir les valeurs que tu envoi (Av/500*sinus[j]), pour toutes les valeurs de j ?
Ton tableau sinus[j] est-t-il bien dimensionné ? (un débordement de tableau est généralement fatal pour un pic ...)
C'est vrai que ca n'a pas forcément qqchose à voir avec ton
"marche po - RESET - marche bien"
mais ... on sait jamais...
après avoir mis en commentaire les sous-programmes "mespt1 et mespt2" le programme se déroule sans problème, je pense que le problème vient des interruptions. Si je met l'un des 2 sous programme en commentaire (mespt1 ou mespt2) même chose cela marche impek. Il semblerait que c'est lorsque je tourne avec 2 interruption que cela pose problème, c'est pour cela que je me posait la question de priorité, surtout que je ne métrise pas trop cet aspect là
c'est un 18F-koi ton pic ? Sur ceux sur lequel je travaille, INT0 est toujours et systématiquement en priorité haute. Pour les autres, c'est réglable dans les registre IPR et INTCON (voir datasheet)
Une interruption "haute" peut interrompre une interruption "basse", alors que deux interruptions de même type s'execute les une après les autres. Comme INT0 est forcément haute, si jamais tu as reglé (ou laissé par defaut) INT1 basse, elle peuvent se gêner réciproquement, surtout si elles accedent à des variables communes ... Donc je te conseillerais de mettre INT1 en priorité haute (pour INT1 c'est INTCON3<6> (INT1IP)... enfin sur mon 18F2x20 ou 18F4x20, s'pareil) ...
Ensuite, vérifie que tu as bien deux routines d'interruptions, une pour les hautes, et une pour les basses, aux bonnes adresses
Extrait de la doc :
Après, si ca ne marche toujours pas, on essayera d'explorer autre chose ... bien que je vais commencer à être à court d'idée ^^The
high-priority interrupt vector is at 0008h and the lowpriority
interrupt vector is at 0018h.
ok, j'utilise un PIC18F4525, j'ai activé la priorité sur INT1 car elle ne l'était pas. Mais il me semble qu'il faut également activé IPEN dans le registre RCON? est-ce juste? mais ce qui est étrange, c'est que lorsque j'extrait les sous programmes mespt1 et mespt2 de cette boucle for et que je les mettent directement dans le main là ça marche
attend attend, j'allais y venir ^^
oui, j'ai oublié un détail tout à l'heure, tu as tout a fait raison, il faut mettre IPEN à 1, ainsi que GIEH et GIEL (registre INTCON).
Ca c'est le premier point.
Ensuite, que font exactement tes deux sous programmes ? Je pige pas le "acquisition voie 1 interruption INT0" et "acquisition voie 2 interruption INT1"
... ?
mespt1 (mesure point 1 ?) vient lire une valeur de quel type, sur quel pate ? pourquoi utiliser INT0 et INT1 qui sont des interruptions sur front (parametrable) des entrées RB0 et RB1 ...
Peut-être que je pose trop de question et que tu va devoir me tuer après si tu me répond, mais ca à l'air de rejoindre ma toute premiere remarque de ce matin :
Pour moi une inettruptions est générée par un evenment exterieur au programme ...mais je peux me planter ...gloups ... un peu confu tout ça ... des interruptions dans un for ?
Mes 2 sous programmes viennent relever une "pseudo" liaison série sur des CAN 24bits. Je dois faire une détection de front sur un signal de synchro que m'envoit ces CAN pour ensuite récupérer les données qu'il m'a converti. Cela se fait sur les pates RB0 et RB1. Indépendament de la boucle for les sous programme marche nikel, je récupère les données que je veux, même chose quand je met cette boucle for directement dans le main...Ce qui est bizarre c'est que si cela venait d'un événement extérieur cela ne marcherait pas non plus lorsuqe je déplace tout dans le main....
ouep, bienvenu dans le mystère PIC ... ok je pige mieux.
...
...
mais ca m'avance pas.
C'est à quelle fréquence de fonctionnement ? Je m'explique :
d'après ce que j'ai compris, dans ton INT0 et INT1, tu informes ton programme qu'un CAN est prêt, puis tu lances la routine (le for...) pour choper les données. Je sais, pour en avoir discuter avec un contact professionel Microchip (un Monsieur qui "parle PIC") que des appels de fonctions dans des interruptions empêche le pic de traiter ces interruptions à des fréquences trop élevé. Quand tu déplaces dans le main, on est plus dans l'interrupt, donc ca marche, c'est ce qui me fait penser à ça ...
Ta fonction CNA_Start est appelé par l'interruption, c'est ça ? Tu as vérifié qu'elle ne prend pas plus de temps à s'executer (tu as quand meme un paquet de boucle for imbriqué, 2x128x69xDelta itérations !) que l'écart de temps entre deux interruptions ?
Sinon, sans le code sous les yeux et le problème complet devant le nez, j'ai pas d'autre idée... Si la gestion des priorité n'a pas résolu ce problème de reset, que c'est pas à cause d'appels de fonctions intempestifs... je ne vois pas...
Daemonight, je crois que tu va pouvoir me fouéter, en démontant le PIC de son support, une petite particule d'epoxy du circuit imprimé c'était foutu dans la broche numéro 1 et magique il s'agit de la broche reset. ça devait faire faut contact et résultat, cela tourne maintenant. Vraiment dsl de tavoir pris du temps, ya des jours comme ça, on aurait mieux fait de rester couché...Merci encore...
a ba finalement j'ai parlé trop vite, ça recommence...
Int 0 et Int 1 me permettent de de savoir quand une données converti est prête à être prendre, quand l'interruption survient j'envoi une trame au CAN puis je récupère les valeurs converti, tout ça se fait dans les sous programme mespt1 et mespt2. Les interruption se font dans ces sous programmes.
Ensuite j'appelle ces sous programme dans la routine CNA_START, cette routine me permet de faire une acquisition sur 2 voies avec simultanément un sinus transmis sur un CNA en SPI selon un période paramétré. Je ne sais pas si je me fais comprendre....
Le problème vient visiblement de l'imbrication des boucles for. Lorsque je réduit le nombre de boucles ça s'arrange. Le simple fait de tout déplacer directement dans le main ne résoud pas le problème. C'est franchement embétant.
dsl de ne pas pouvoir te donner le code complet mais cela rentre dans le cadre d'un projet pour mon entreprise, donc confidentialité et tout ce qui va avec...
oui oui j'avais compris pour la confidentialité ^^
ca me paraissait trop simple, le bout d'epoxy, en tout cas ca me fait plaisir de constater que je suis pas le seul à aller jusqu'a démonter le PIC "pour être sur" (de quoi, on ne sait pas, mais pour etre sûr quand meme).
sorry mais je pige toujours pas ton :
pour moi tu es en train de me dire que quand INT0 survient, tu lances mespt1, et l'interrutpion se fait dans mespt1 ... Donc l'interruption se lance elle-même ???quand l'interruption survient j'envoi une trame au CAN puis je récupère les valeurs converti, tout ça se fait dans les sous programme mespt1 et mespt2. Les interruption se font dans ces sous programmes.
bref. Tu dis que quand tu baisses la valeur des boucles for, ca marche. Tu as vérifié ce que je t'ai dis plus haut, cette histoire de plus de 17000 appels de mspt1 et mspt2 ?
franchement merci de persévérer sur mon problème, je l'ai tourner dans tout les sens. J'ai supprimé les boucle for une a une pour voir, j'ai également réduit la valeur de leur index mais rien y fait si ce n'est que ça plante plus ou moins tard.
Je vais essayé d'être plus clair dans le fonctionnement de mes SP mespt1/2:
lorsque je rentre dans l'un des ces sous programme:
- J'active l'interruption sur la broche correpsondante;
- J'attends qu'un front montant arrive
- je change la polarité de l'interruption (front descendant)
En parallèle j'avais lancer un timer pour calculer la durée entre les 2 fronts détectés.
Si la durée correspond à ce que je veux, je sort du SP d'interruption (qui n'est pas CNA_Start) sans oublié de désactivé les interruptions et de remettre les flag à 0.
- Je balance ensuite une trame vers mon CAN et je récupère les données converties qu'il m'envoi sur une autre broche.
Je vient donc consulter ces 2 voies l'une après l'autre et ce pendant que j'envoi en même temps des données vers un CNA SPI. C'est cette partie qui se fait dans le sous programme CNA_Start. Donc pour rappel, quand je met uniquement une voi d'acquisition ça marche et quand j'en met 2 ça plante à des moments aléatoires dans la boucle for.
Je veux bien vous donné mon sous programme d'interruption mais je ne suis pas sur que cela avance a grand chose:
Néanmoins j'ai remarqué quelques chose c'est que lorsque je met mes petits bouts de code (test passage dans boucle) en commentaire et bien là ça fonctionne encore moins bien, ça plante comme lorsque j'active mes 2 sous programme mespt1/mespt2. Serait-ce les routine "delay" qui poseraient problème??Code:void interrupt() { if (INTCON.INT0IF) //interruption sur sdout1 { if (edge1 == 1) //si présence d'un front montant { PORTB.pintest1 = 1; //test passage dans boucle delay_us(25); PORTB.pintest1 = 0; delay_us(25); TMR1H = 0; //Mise à zéro TIMER1 TMR1L = 0; PIR1.TMR1IF = 0; //Remise à zéro flag débordement TIMER1 INTCON.INT0IF = 0; //Remise à zéro flag INT0 T1CON = 1; //Start TIMER1 INTCON2 = 0x80; //config interupt sur front descendant edge1 = 0; } else if (edge1 == 0) //si présence d'un front descendant { T1CON = 0; //Stop TIMER1 PORTB.pintest1 = 1; //test passage dans boucle delay_us(25); PORTB.pintest1 = 0; delay_us(25); if (PIR1.TMR1IF) {edge1 = 1; return; } if (TMR1H > 4) {edge1 = 1; return; } if (TMR1H < 1) {edge1 = 1; return; } INTCON = 0; // desactive Interupt Int0 INTCON3 = 0; // desactive Interupt Int1 INTCON2 = 0xF0; //config Interupt sur front montant edge1 = 1; t1match = 1; } } if (INTCON3.INT1IF) //interruption sur sdout2 { if (edge2 == 1) //si présence d'un front montant { PORTB.pintest1 = 1; //test passage dans boucle delay_us(25); PORTB.pintest1 = 0; delay_us(25); TMR1H = 0; //Mise à zéro TIMER1 TMR1L = 0; PIR1.TMR1IF = 0; //Remise à zéro flag débordement TIMER1 INTCON3.INT1IF = 0; //Remise à zéro flag INT0 T1CON = 1; //Start TIMER1 INTCON2 = 0x80; //config interupt sur front descendant edge2 = 0; } else if (edge2 == 0) //si présence d'un front descendant { T1CON = 0; //Stop TIMER1 PORTB.pintest1 = 1; //test passage dans boucle delay_us(25); PORTB.pintest1 = 0; delay_us(25); if (PIR1.TMR1IF) {edge2 = 1; return; } if (TMR1H > 4) {edge2 = 1; return; } if (TMR1H < 1) {edge2 = 1; return; } INTCON = 0; // desactive Interupt Int0 INTCON3 = 0; // desactive Interupt Int1 INTCON2 = 0xF0; //config Interupt sur front montant edge2 = 1; t2match = 1; } } }
panne sèche ...
je comprends bien ce qeu tu fais, j'imagine bien comment cela s'articule, je me projette bien en me disant que j'aurai sûrement fait quelque chose dans ce goût là, mais alors pourquoi ca marche une fois sur deux ...
les délai_us(), je ne m'en sert plus depuis que un moment, j'essaye toujours de trouver des alternativeq, justement parce que je trouve que ce n'est pas très propre, mais de là à dire que je problème vient de là...
non, je sèche. Désolé. Si jamais tu trouves, j'aimerais bien un retour pour ma gouverne personnelle ... En attendant bon courage
