[RESOLU] Problème incompréhensible

Bonsoir à tous,

Celui qui me trouve la solution à ce problème aura droit à tout mon respect :slight_smile:

Background : je développe un projet avec une carte maison à base d’Atmega32u4. Je fais mon développement, je programme, ajoute les fonctions au fur et à mesure … Et paf à un moment j’upload et mon Atmega freeze et n’est plus reconnu sur mon ordi … J’avais pas prévu de port ISP donc je soude des fils, re-up le bootloader et on repart. Je re-up le code => re-freeze … Je re-up le bootloader, charge un autre code quasiement similaire => fonctionnement OK. Hum …
Je prend mon code à problème, le up sur un clone à base d’Atmega32u4 => même constat, ça brick …
Après des heures passez à ré-up le bootloader et à éliminer les lignes qui ne posait pas problème je suis arriver au code suivant.

Attention : si vous l’uploader sur votre carte il y a de grande chance qu’il vous fasse reprogrammer le bootloader derriere. Je vous aurais prévenu …

#include <TFT.h>  // Arduino LCD library
#include <SPI.h>
#include <TMC222.h>
#include <Wire.h>

TMC222 svt1(0b1100001);
TMC222 svt2(0b1100000);
TMC222 svt3(0b1100011);
TMC222 svt4(0b1100010);

struct Buffer {
  char items[18][18];
  int color[18][18];
};
  
TFT TFTscreen = TFT(9, 4, 11);

Buffer displayBuffer;
Buffer displayBufferOld;

void setup() {

  tone(5,440,500);
  
  memset(displayBuffer.items, '\0', 1); 
  memset(displayBufferOld.items, '\0', 1); 

}

void loop(){
  
}

Petites précisions :

  • TMC222.h est une lib maison pour les TMC222 qui sont des drivers i2c pour stepper, voir ici : GitHub - battosai30/TMC222
  • Si vous commenter n’importe quelle ligne, le code fonctionnera. Ce n’est pas une ligne en particulier qui fait tout foirer, mais l’ensemble.

Sous Windows 7 et IDE 1.0.5

B@tto: ...

Après des heures passez à ré-up le bootloader et à éliminer les lignes qui ne posait pas problème je suis arriver au code suivant.

Bonsoir B@tto A chaud , mais je pense que tu y aura pensé/regardé ton code ne génère t'il pas une "pseudo séquence" d'échappement interpretée ? genre le bug des 3 !!! (de mémoire , pas sur que ce soit !!! :sunglasses: )

En mettant en remarque la lib TMC222 et les objets svt1, 2, 3 et 4
La compilation retourne ça:

Le croquis utilise 12 342 octets (43%) de l'espace de stockage de programmes. Le maximum est de 28 672 octets.
Les variables globales utilisent 2 460 octets (96%) de mémoire dynamique, ce qui laisse 100 octets pour les variables locales. Le maximum est de 2 560 octets.
Peu de mémoire disponible, des problèmes de stabilité peuvent survenir

Autant dire que tu n’as plus de RAM

hello les fous, c'est quoi ce bug des 3? histoire de me coucher moins idiot :) sinon, mis à part un conflit d'adressage dans ta lib et celle de SPI, je vois pas trop. question conne, ca me changeras pas trop, si rien n'est connecté sur ta carte, ca fait la même chose?

j'aurais parlé de flash saturée, mais en effet, c'est la ram qui sature, donc dès que tu appelles la pile, hop, et zouuuuuuuuuuuuuuuuuuuu!

va falloir optimiser tes variables... bonne chance!

@infobarquee http://forum.arduino.cc/index.php?topic=46966.0 et https://code.google.com/p/arduino/issues/detail?id=392

ha ok, merci le coup de 3 ! qui fait que ca compile et plante derrière.

Merci pour votre aide :)

Pour la RAM : j'y avais pensé, mais je vois pas ce qui la bouffe dans ma lib : y'a ~50 bytes de variables

Je vais quand même vérifier physiquement le remplissage de la RAM. Mais ce qui me fait aussi douter de cette hypothèse c'est que ce code la est extrêmement raccourci comparé à celui d'origine, et si c'était effectivement un problème de RAM saturée ça aurait dû arriver bien avant dans mon développement. Après est-ce que j'étais juste borderline sans le savoir et que mes instanciation supplémentaires ont achevé la bête ...

struct Buffer {[color=#222222][font='DejaVu Sans Mono', Monaco, Consolas, monospace][/font][/color]
  char items[18][18];[color=#222222][font='DejaVu Sans Mono', Monaco, Consolas, monospace][/font][/color]
  int color[18][18];[color=#222222][font='DejaVu Sans Mono', Monaco, Consolas, monospace][/font][/color]
};

Ta librairie n’est pas en cause. J’ai compilé sans puisque je ne l’ai pas.
Ce sont juste les données que tu déclares et la librairie TFT

18x18 = 324
324*2 + 324 = 972
Ta structure occupe presque 1kB et tu en déclares deux. Faut pas trop t’étonner.

Oh punaise pas faux du tout ... J'avais même pas fait ce calcul ...

Bon bah résolu alors xD

Merci beaucoup en tout cas !

B@tto vient de inventer une méthode soft pour faire un erase du bootloader :) trop fort le gars

EDIT (grâce à la team Arduino ) j'ai oublié de dire que j'aime les hommes :)

Effectivement il est assez clair que la capacité de la RAM était dépassée et que cela faisait planter le programme. En revanche je ne comprends pas en quoi cela a bien pu affecter le bootloader...

En fait le bootloader n'a pas l'air vraiment corrompu : si je fait un reset hard, la led 13 "respire bien" et la carte est bien identifié en "leonardo mode bootloader". Mais après la période de timeout elle n'est plus reconnu ("périphérique USB non identifié") et l'IDE ne la détectant plus il ne veut pas lancer l'upload. Et comme il faut qu'elle soit en mode "USB normal" avant le mode "USB bootloader", même en faisant un hard reset au bon moment il refuse l'upload ...

Donc je pense tout simplement que les infos USB VID/PID sont écrasées ou corrompues à l'initialisation des variables de mon code puisque ces infos de mémoire ne sont pas programmer dans la flash (histoire de gratter sur l'empreinte en mémoire) et donc le PC ne reçoit plus les bonnes infos et est par la même incapable de le reconnaître.

Ah oui, c'est certainement l'explication. Je n'avais pas fait attention qu'il s'agissait d'un 32u4 et du coup je ne comprenais pas comment tu avais pu en arriver à la situation où même le bootloader ne répondait plus (ie les symptômes auraient été différents sur une Uno). Mais là ça se tient :)