Perte de programme avec Uno...

Bonjour,

Sur un de mes projets, il m'est arrivé à 2 reprises (dont ce week-end) qu'il n'y ait plus de programme dans l'Uno. J'ai dû le télécharger à nouveau...

Le sketch tournait depuis des semaines sans souci. Pendant plusieurs semaines j'ai observé la RAM disponible, et la valeur ne changeait pas...

Quelles sont les raisons qui peuvent expliquer ce problème ?

Merci pour vos lumières,

bonjour, le code ne s'efface pas sur la carte, peut être un overflow de la mémoire. sans code difficile de le dire.

n'y aurait il pas un truc de gestion de temps et qui a buggé au bout de 40-45j?

Merci pour la réponse,

De quelle mémoire parles-tu ?

Hummm, j’imagine que tu penses à millis(). Effectivement, j’utilise la fonction millis() dans différentes fonctions…
Je n’y avait pas pensé !

Comment remédier à ça ?

Merci,

Dans un programme prévu pour tourner plus de 49 jours, il ne doit jamais y avoir if (millis() > ...)

Pour mesurer une durée correctement, sans avoir d'ennuis au bout de 49 jours quand millis() repasse à zéro, le code correct est :

unsigned long int debut;
...
  debut = millis();
...
  unsigned long int duree = millis() - debut;
  if (duree > ...)

Ou alors utiliser un simple minuteur

Ceci étant dit, si un reset n'a pas résolu le problème, et qu'il a fallu téléverser à nouveau le programme, c'est que le mal est certainement plus profond qu'un débordement de millis().

Il faut plutôt chercher du côté des mémoires non volatiles.

Tu écris dans l'eeprom ?

Merci pour vos suggestions,

Je n'ai pas le sketch sous la main et ne peut donc vérifier...

  • Non, je n'écris pas dans l'eeprom, du moins pas dans la boucle principale. Seulement une fois lors de la calibration.

-Je vais regarder où j'utilise la fonction millis(). De mémoire, à un endroit pour afficher le temps de téléchargement et un autre comme timer d'attente de réponse. Mais il me semble avoir utilisé la méthode décrite par bricoleau.

Comme dit, la RAM mise sous surveillance n'évoluait pas pendant des semaines.... Je n'utilise pas l'eeprom. Que reste t-il ?

Merci,

tk5ep: Merci pour vos suggestions,

Je n'ai pas le sketch sous la main et ne peut donc vérifier...

  • Non, je n'écris pas dans l'eeprom, du moins pas dans la boucle principale. Seulement une fois lors de la calibration.

-Je vais regarder où j'utilise la fonction millis(). De mémoire, à un endroit pour afficher le temps de téléchargement et un autre comme timer d'attente de réponse. Mais il me semble avoir utilisé la méthode décrite par bricoleau.

Comme dit, la RAM mise sous surveillance n'évoluait pas pendant des semaines.... Je n'utilise pas l'eeprom. Que reste t-il ?

Merci,

bonsoir comme evoqué par bricoleau si c'etait un probleme de debordement de millis() un simple reset aurait du relancer le fontionnement sans avoir besoin de faire un autre upload.

Pour test il faudrait "initialiser" le compteur millis() proche de son debordement. Jamais fais , mais intellectuellement je pense que ça doit etre assez "simple en codage" de forcer une valuer proche de la limite. Les vrais tripoteurs de registres en pensent quoi ? :grin:

Bonsoir Patrick,

il me semble que tu as déja eu un pb similaire avec ton pro-mini ? utilises tu un watch-dog particulier ou quelque chose qui fasse basculer le uno en mode téléversement ?

un pb du au climat sur ton ile ;)

@+

Bonsoir Christian,

Oui, c’est la 2ème ou 3ème fois que ça arrive… Ça tourne des semaines sans soucis, puis il plante et il me faut à nouveau téléverser le logiciel !

Pas de watchdog, rien de tout ça. Ce n’est pas un simple plantage…

L’idée du millis proche du débordement, est à tester…

@+

Y a quoi de branché autour de la carte arduino (shield compris) ?

Question bête : as-tu essayer de changer le matériel , donc remplacer le Uno ?

A moins de 4€ pièce faut pas se priver.

Ouais mais s'il faut attendre 50 jours pour savoir si ça venait de la carte...

Moi je vote pour le camarade farceur qui te remplace ta carte arduino par une vierge :smiling_imp:

:)

Merci pour vos réponses.

Autour de l'Arduino (pro mini) , il y a du monde connecté... Un BME280 et une RTC sur le bus I2C. 2 platines HX711 2 sondes BS18B20 3 transistors MOSFET qui coupent les alimentations lors des phases sommeil.

Le tout alimenté à partir du 12V, un régulateur low drop 5V. Le précédent plantage avait eu lieu avec un "step-down", donc l'alim à exclure.

Quant à changer l'Arduino, je n'aurais effectivement peut-être une réponse que dans plusieurs semaines..

Merci à tous,

Bonjour,

pour tester le débordement de “millis” en gagnant quelques semaines

un exemple:

//test OK roll over               4 294 967 295----------->0

byte etatPir=0;
byte etatRi=1;

void setup() {
  Serial.begin(115200);
  Serial.println("set up ok");
  delay(2000);
}

void loop() {
Serial.print("valeur millis debut = ");
Serial.println(millis());
chrono(4000);
Serial.print("valeur millis fin = ");
Serial.println(millis());
while(1);
}

void  chrono (unsigned long temps) 
{unsigned long topDep=millis()+4294965000UL;      //+  pour approcher le roll over
unsigned long millis2=millis()+4294965000UL;
while(((millis2-topDep) < temps) && etatPir==0 && etatRi==1)
     {Serial.print(millis2);Serial.print(F(" =millis2  et    topDep= "));
      Serial.println(topDep);
      //return;
      millis2=millis()+4294965000UL;
      
     }
}

3 transistors MOSFET qui coupent les alimentations lors des phases sommeil.

Comment faut-il comprendre cette phrase ? Que commandent ces 3 transistors ? Quels courants mis en jeu ?

Quels courant [u]max[/u] peut être demandé par sortie, par PORT ?

Avant d'aller chercher midi à 14 h je pense qu'il serait bon que tu fournisse un schéma électrique de cablage et quelques explications parce que :

Un BME280 2 platines HX711

peut-être que je suis le seul à ne pas connaître mais cela ne me dit absolument rien.

Dernière question : te souvient-tu s'il y a eu ou non des manip un peu douteuses lors de la mise au point ? En général cela arrive très souvent, même si, hélas, on ne s'en rend pas forcément compte. C'est pour cela qu'au prix actuel des cartes il est préférable de ne pas utiliser en production la carte qui a servi pour la mise au point.

Bonjour et merci pour toutes ces remarques constructives,

Le problème ne semble pas évident à cerner…

Je ne pense pas que le problème vienne du dépassement millis(). J’ai vérifié sur mon sketch et je pense bien gérer cette fonction. Par ailleurs, je ne vois pas pourquoi un dépassement pourrait faire planter la totalité de mon sketch et surtout bloquerait l’Arduino.

Ensuite, il n’y a pas eu 49 jours de fonctionnement ininterrompu, il y a eu des reset et M/A par déconnexion de l’alim entre temps.

Maintenant, j’ai du mal à savoir quand a eu lieu le dernier reboot…

Pour répondre en vrac :

  • il s’agit d’un clone chinois de Pro mini 5V/16MHz. Je ne connais pas la version du bootloader.
  • valeurs des fuses et lockbit inconnues
  • je le programme via le port série à 57600 bauds dans son environnement
  • le bouton RESET fonctionne en temps normal
  • le BME280 est une sonde I2C de température, humidité et pression
  • le HX711 est un convertisseur ADC de 24 bits
  • le courant max consommé par la platine est de 2A, par le GSM
  • une fois planté, je n’avais plus aucune réaction de l’Arduino. Un appui reset ou M/A ne donnait rien
  • ci-joint le schéma
  • le sketch étant long, je préfère l’envoyer en MP
  • le montage est réalisé sur une veroboard et les modules connectés “sur table”. Le GSM est à proximité, mais je ne vois pas pourquoi il serait la cause si rien ne change dans l’environnement.
    Le dernier plantage a eu lieu vers 20h alors que personne n’était sur place et aurait pu bouger quelque chose.

Maintenant, je peux changer la platine mais je ne me souviens pas avoir eu des “problèmes” lors du développement…

Que faut-il que je fasse pour m’en prévenir ?

Que faut-il que je fasse la prochaine fois que ça arrivera ?

Je ne connais pas AVRDUDE, je vais regarder de quoi il s’agit.

Merci encore pour le temps passé à me répondre.

Cordialement,

avrdude : Comme Mr Jourdain tu te sers régulièrement d'avrdude sans le savoir. C'est le logiciel , [u]écrit par ATMEL[/u], qui sert à écrire [u]et à lire[/u] dans les micro de technologie avr. Tu peux, avec l'aide de la datasheet d'avrdude, trouvable avec ton butineur favori, lire et vérifier les fuses, plus d'autres choses. Un site pour t'aider : http://www.engbedded.com/fusecalc Un détail qui a son importance : les fuses ne sont plus des fusibles comme il y a 50 ans mais une zone spéciale de l'Eeprom. Il se trouve que du fait de la technologie employée une cellule Eeprom en mode "sortie de fab" c'est à dire non programmée est à l'état logique 1. C'est comme cela, point. Pour diminuer au maximum ses opérations INTERNES Atmel à choisi une logique inversée : - Niveau logique non programmé donc ZERO LOGIQUE = 5V - Niveau logique programmé donc UN LOGIQUE = 0V C'est parfaitement "légal" même si cela peut en dérouter certains.

La programmation à 57600 bauds est classique pour micro-pro et nano. Franchement, à moins que ta platine soit entrée dans le réacteur de Tchernobyl je ne vois pas pourquoi les fuses serait dé-programmés.

Une liaison me choque sur le schéma : le 5V en sortie du régulateur LM2931-A 5V est appliqué sur l'entrée RAW qui elle est l'entrée d'un autre régulateur 5V [1].

[1] Sauf si le mini-pro que tu utilise est un modèle 3,3V, soit c'est une erreur dans le dessin soit si c'est effectivement câblé ainsi et cela ne peut fonctionner que très aléatoirement. De toutes façon il faudrait que tu vérifies toutes les tensions statiques avec un voltmètre pour s'assurer qu'elles sont conformes a tes attentes.

Merci pour vos remarques et analyses,

L'Arduino pro-mini est bien un 5 V, il y a un régulateur 3V3 dessus (marqué KB33) d'où l'alimentation en 5V par l'entrée RAW.

Les tensions statiques sont correctes.

Effectivement, il doit y avoir conflit avec les tensions des HX711. Mais comme ça marchait bien, je n'ai pas creusé le problème... :-) Je vais cependant soit adapter les niveaux, soit alimenter la partie digitale des HX711 en 3,3V. Je viens de brancher une platine que j'ai réalisée qui comporte un régulateur 5V faible bruit et un HX711 en version minimale, mais surtout avec un plan de masse sur le circuit et des connexions optimisées, pas comme sur les platines chinoises... J'ai donc séparé les alimentations analogiques et digitales du HX711, ce qui devrait faciliter le test en 3,3V.

Il faut que je vérifie cependant si le HX711 permet cette acrobatie. C'est une des raisons pour laquelle je n'ai trop creusé ce problème. Il faut que la sonde de poids soit alimentée avec la tension la plus élevée possible pour augmenter le niveau très faible de sortie.

Pour le port RS232, j'utilise en adaptateur USB/TTL. L'annotation RS232 sur le schéma est donc erronée, je vais remplacer par TTL.

OK pour AVRDUDE.

Merci encore,

Et si le fabricant est sérieux cela signifie aussi que le résonnateur est à 8 MHz.

A 3,3 V Atmel ne garanti qu'une fréquence max de 12 MHz. Certains passent outre parce qu'en général cela fonctionne à 16 MHz. Mais comme toujours il existe des lots de fabrication qui sont dans la spec des 12 MHz mais qui ne fonctionnent pas à 16 MHz.

Je viens de retrouver une carte mini-pro et effectivement j'avais confondu avec la Nano (un regul 5V + le 3,3 V fourni par le CH340G ), sur la mini-pro il n'y a qu'un seul régulateur à 3,3V.

Autre point : sur la carte que je viens de retrouver il y a une diode 1N4007 en série avec l'alim : gros pavé marqué M7. Elle sert pour éviter que les maladroits qui branchent l'alim à l'envers ne tuent la carte. Si sur ta carte il y a la même protection, à l'intérieur de la carte (et notamment sur les sorties digitales), tu ne devrait pas mesurer un Vcc à 5 V mais à 4,2V/4,3V.

Si la diode gène le fonctionnement tu peux la court-circuiter (si tu ne fait pas partie des maladroits :grin:)

Petite disgression, c'est du détail mais autant le connaître:

L'annotation RS232 sur le schéma est donc erronée, je vais remplacer par TTL.

Mon brave Monsieur même l’appellation TTL est erronée :grin: .

Elle est vulgairement et largement utilisée pour dire que l'amplitude des signaux est de 0V /+ 5V. Or la TTL ne fonctionne pas en 3,3 V :disappointed_relieved: Or c'est aussi (et ce n'est pas le moins important) de la logique à base de transistor bipolaire avec un seuil de basculement :

La technologie TTL est normalisée pour une tension d'alimentation de 5 V. Un signal TTL est défini comme niveau logique bas entre 0 et 1,4 V, et comme niveau logique haut entre 2,4 V et 5 V

Donc pas grand chose à voir avec la logique de technologie CMOS utilisée largement de nos jour où le seuil de basculement est spécifié non plus en fixe mais par rapport à Vcc : niveau bas entre 0 et 0,3 Vcc, niveau haut entre 0,7 Vcc et Vcc

Mais comme le terme TTL est très utilisé (de travers) il faut le connaître, ne serait-ce que pour acheter sur Ebay, et savoir que les niveaux sont CMOS et non pas TTL.

La RS 232 c'était 1 protocole + des signaux logiques le tout dans la même norme. C'était une erreur de tout mélanger. Actuellement elle a été éclatée: - d'une part le protocole de transmission dit "série" mais dont le nom officiel est UART pour Universal Asynchronous Receiver Transmitter et USART pour Universal Synchronous/Asynchronous Receiver Transmitter

  • de l'autre la norme des signaux : RS485, CMOS etc....