DS des commandes du module GSM2 : https://www.quectel.com/UploadImage/Dow ... l_V1.2.pdf
Voila quelques semaines que je me suis remis à essayer de faire quelques choses avec mon module GSM2. Le but étant de pouvoir faire un peu de domotique à la maison. Genre allumer une lumière pour commencer, mais pour cela il faut que j'arrive fiabiliser mon programme et ce n'est pas gagné !
Le bug que je vais tenter de vous expliquer ci dessous, je n'arrive pas à le reproduire à tout les coups, des fois ça fonctionne pendant 20 minutes et 20 SMS envoyés, des fois ça plante assez vite. Je n'ai pas réussis à mettre le doigt sur la cause exact de ce plantage, mais je pense avoir trouvé où il ce situait mais sans l'expliquer .
Je précise que mon programme fonctionne très bien en temps normal, mais à un moment pouffff ça veut plus.
le programme ce compose en 4 fichiers :
- le programme principal
- l’interruption sur réception UART (machine d'état)
- Une fonction analyse du SMS entrant qui renvoie un numéro de réponse approprié
- et une fonction envoi de la réponse par SMS .
Pour ceux qui ont MIKROC vous pouvez décompressez cette archive et ouvrir le programme :
Les autres courageux qui veulent jeter un œil devront ouvrir les .C avec un éditeur de texte.
Pour diagnostiquer le problème j'espionne le dialogue entre le PIC et le module GSM avec un cordon et "realterm". Je ne peux espionner qu'un seul tuyau à la fois mais cela reviens au même au final. Que j'espionne le tuyau PIC<->GSM2 ou GSM<->PIC le problème reste le même sans information supplémentaire
Rentrons dans le vif du sujet .
Le fonctionnement de mon programme :
- Toute les secondes je demande au module radio de m'afficher les messages à l'emplacement #1 avec la commande "AT+CMGR=1".
- Si je n'ai pas de message le module me revoit "OK". je reboucle .
- Si j'ai un message, il me le renvoi avec des "mots clés" et fini aussi par "OK".
Pendant qu'il m'envoie son message, je l'examine ( les mots clés) avec la machine d'état et lève certais drapeau en fonction des mots clés recus. J'attends toujours la fin de l'envoi du message indiqué par un "OK". Ainsi je m'assure d’avoir bien tout lu le message. Plutôt que de mettre une pause qui est assez aléatoire.
Si le drapeau "UNREAD" ou "READ" est levé c'est que j'ai un message à l’emplacement #1. Donc je dois l'analyser pour savoir qu'elle réponse envoyée. De la je pars sur ma fonction analyse SMS .
cette fonction indique un numéro de message en retour quelle stocke dans une variable.
Une fois analysé, je vais dans ma fonction ENVOI _SMS :
- Suivant le numéro du message je compose ma réponse.
- J’envoie la commande pour envoyer un message "AT+CMGS= numero de tel".
- J'attends que le module soit prêt a le recevoir. ( la petite flèche)
- Une fois la petite flèche reçue, je lui envoi le texte du message a renvoyé.
Et voila je reviens au programme principal et je fais clignoter ma led pour dire que j'ai reçu un SMS ( chiffre impair pour changer l'état de la LED)
Dans l'idéal tout devrait se passer comme ça !
Le problème maintenant:
A un moment (non défini), je ne reçois plus aucune réponse. Mon module GSM2 reçoit bien un message, car les leds clignotent. Dans la théorie cela signifie aussi qu'il passe par la fonction "analyse " et la fonction "ENVOI".
Dans tous les cas, si mon module reçois un message, correct ou non, il doit me renvoyer une réponse. La fonction analyse met toujours une valeur dans la variable numéro de message. je ne vois pas de "BUG" possible ici.
Ensuite viens l'envoi du SMS . C'est donc ici le départ du BUG.
Pour envoyer un SMS, il faut envoyer une commande au module. cette commande c'est "AT+CMGS = numéro de téléphone" que j'ai remplis lors de l'analyse du SMS.
Lors du BUG ce message ne part jamais! a partir de la déjà je ne comprends pas. Quoi qu'il arrive le PIC devrait envoyé au module cette commande ("AT+CMGS= numero de tel" ). Donc si il ne l'envoi pas, forcement pas d'envoi de SMS. Voila source du problème.
J'essaye donc de remonter le fil du BUG et c'est la mon incompréhension totale. Car il n'y a pas de condition pour envoyer cette commande. j'entends par la , que si on rentre dans la fonction, forcement il doit m'envoyer cette commande ("AT+CMGS= numero de tel") !!! Hors je ne la vois pas à l'espionnage. cette commande n'est pas envoyée .
Je me dis que si cette commande n'est pas envoyée c'est que je n’exécute pas cette fonction. Donc je continue à remonter le bug
Cette fonction n'a qu'une seule condition d’exécution, pour s’exécuter il faut qu'il y ai un nouveau SMS. Hors le PIC à bien reçu un nouveau SMS car les leds clignotent donc je suis bien obligé d’exécuter cette fonction. La je suis perdu ! La fonction est obligé de s’exécuter, l'envoi de la commande est obligé de ce faire et pourtant rien ne se fait !
J'ai fais en sorte que rien ne reste bloquant indéfiniment. dans tout les cas, si un bug survient au bout d'un moment , on revient en position claire.
POURQUOI donc , cette commande n'est pas envoyée ? alors que je suis sûr que le PIC exécute la fonction ? telle est la question ?
J'ai remarqué qu'avant ce problème ci, il s'en produit un autre. Même si cet autre problème ne devrait en rien interférer dans le second. Et vous savez quoi ? je ne comprends pas non plus le premier bug et pourquoi il est a l'origine du deuxième bug.
A un moment donné, comme d'habitude je demande à lire les messages, il m'affiche un message un non lu, puis dans la foulée il m'affiche un message lu ! alors que dans la théorie je ne lui demande pas. Si j'ai un message non lu, il devrait le traiter puis l'effacer dans la foulée. Hors la, non !!!
La je comprends pas comment c'est possible, sauf un problème avec le module GSM2.
Et même si ce bug se produit, pourquoi ensuite, je ne n'arriverai pas a envoyer d'autre message !
Voici en image l'espionnage fait au moment du bug . Je précise qu'avant cela tout a fonctionner sur de nombreux SMS. C'est à ce moment précis que ca bug.
