Effacer completement le programme d'une Mega

Salut,

J'imagine que si tu upload un programme de 3Ko puis ensuite un autre de 1Ko, l'upload ne doit pas inscrire des 0 dans les 2Ko suivants de la flash (sinon, bonjour les temps d'upload à chaque fois s'il faut remettre à Z toute la flash!). C'est comme un disque dur, les données ne sont pas effacées à la simple suppression d'un fichier, mais n'étant plus référencées, elles seront un jour écrasées par une autre écriture.

Dans ce cas, il restera des vieux morceaux de code dans les 2Ko de flash en question, mais est-ce vraiment gênant?

Super_Cinci:
Salut,

J'imagine que si tu upload un programme de 3Ko puis ensuite un autre de 1Ko, l'upload ne doit pas inscrire des 0 dans les 2Ko suivants de la flash (sinon, bonjour les temps d'upload à chaque fois s'il faut remettre à Z toute la flash!). C'est comme un disque dur, les données ne sont pas effacées à la simple suppression d'un fichier, mais n'étant plus référencées, elles seront un jour écrasées par une autre écriture.

Dans ce cas, il restera des vieux morceaux de code dans les 2Ko de flash en question, mais est-ce vraiment gênant?

Pas sur de ce que tu avances, parce que sinon, l'upload d'un programme "vide" n'effacerait justement pas le précédent.

Le bootloader aurait une commande d'effaçage complet de la flash?

Afin d'être sur il faudrait pouvoir lire la totalité du contenu et l'afficher puis faire des tests d'effacement, là on serait sur de la réponse et de la conduite à tenir, mais bon je ne sais pas si c'est possible.

Savoir qu'il peut rester des bouts d'un ancien programme, ok. Maintenant, je me dis que si c'est pas du code sensible contenant des algos sous brevet ou secret-défense, est-ce que ça dérange? La flash est une zone qui contient dans une partie le code utile, dans le reste, je dirais que c'est un espace de stockage comme l'eeprom, c'est-à-dire que les données se trouvant là, si on les lit, c'est qu'on en a besoin et qu'on les avait écrites volontairement...

:roll_eyes:

Afin d'être sur il faudrait pouvoir lire la totalité du contenu et l'afficher puis faire des tests d'effacement, là on serait sur de la réponse et de la conduite à tenir, mais bon je ne sais pas si c'est possible.

En même temps quel est l’intérêt?
Si des octets d'un ancien programme ne sont pas effacés on a aucune raison d'exécuter ce code sauf si on fait une erreur dans le programme qui a été écrit après.
Donc normalement on ne doit jamais retomber dans l'ancien code.

Bon un bout de code pour les curieux

#include <avr/pgmspace.h>


PROGMEM prog_char octet[] = {0};		

void setup(void){
  unsigned int i,j;
  unsigned char myChar;
  
  Serial.begin(9600);
  Serial.println();
  Serial.println("Dump memoire programme");
  for (i=0;i<32768;i+=16){
    Serial.print(i,HEX);
    Serial.print(" : ");
    for (j=0;j<16;j++){
      myChar =  (pgm_read_byte_near(octet + i+j) & 0xFF);
      //myChar =  i & 0xFF;
      if (myChar<0x10)
        Serial.print("0");
      Serial.print(myChar,HEX);
      Serial.print(" ");
    }
    Serial.print("   ");
    for (j=0;j<16;j++){
      myChar =  (pgm_read_byte_near(octet + i+j) & 0xFF);
      //myChar =  i & 0xFF;
      if((myChar>0x20) && (myChar<128))
        Serial.write(myChar);
      else
        Serial.print(" ");
    }
    Serial.println("");
  }
}

void loop(void){
}

Affiche le contenu de la mémoire. L'origine n'est pas le début de la mémoire mais l'adresse de la variable octet. De ce que j'ai pu voir cette variable est au début de la mémoire car au bout de quelques lignes je trouve ma chaine de titre "Dump memoire programme".
Le programme est fait un peu à l'arrache. J'ai fixé la longueur du dump à 32768 directement dans le code, suivant le micro utilisé il faudra peut être changer.
Et les lignes se décalent suivant l'adresse, j'ai oublié de tester la longueur de l'adresse pour aligner les colonnes.

En tout cas cela confirme que la mémoire n'est pas effacée au-delà du nouveau programme j'ai retrouvé des "restes" de vieux programmes que j'ai fait il y a un bon bout de temps.
Mais comme je le disais au début on ne doit jamais retomber dans le vieux code sauf plantage.

La tournure de cette discutions pourrait inspirer un épisode des experts, dont la clé de l'énigme aurait été de retrouver un morceau de code a moitiez supprimer a l'intérieur d'une eeprom qui aurait permis un meurtre :D.

fdufnews:
Mais comme je le disais au début on ne doit jamais retomber dans le vieux code sauf plantage.

Plantage, oui, mais du au compilateur, c'est loin d'arriver ça...

lacolombenoir:
La tournure de cette discutions pourrait inspirer un épisode des experts, dont la clé de l'énigme aurait été de retrouver un morceau de code a moitiez supprimer a l'intérieur d'une eeprom qui aurait permis un meurtre :D.

Oh lacolombenoir à quoi il te sert ton arduino? Dans le mien il n'y a que des trucs bien innocents....

Mon Arduino n'a tuer personne pour l'instant, si sa peu te rassurer,
Mais qui-sais grâce à se topic un tueur a l'arduino pourra assurée c'est arière XD.

Pour résumer et faire simple,
tant que le nouveau programme reste inférieur à l'ancien il reste obligatoirement la suite de l'ancien programme.
Il n'est nécessaire de supprimer ce reste car il n'est pas gênant pour le fonctionnement.
Pour vider la mémoire dans la boucle de fdufnews il faudrait rajouter l’écriture de "FF"" dans le cas ou la lecture serait différente mais bon
au final il n'y aura rien a gagner.

Bonjour,
Y a-t-il un moyen de lire le programme uploadé ?
Ainsi, on pourrait savoir tout ce qui traine dans la mémoire flash, ce qui pourrait aider.
De plus, on saurait comment le programme est enregistré dans la carte (sous quelle forme).

Sinon, pourquoi la carte n'effacerait pas toute la flash au changement de programme ?
Question temps, on n'est pas à ça près...

Le programme est compilé avant d'être uploadé dans la carte.
Un dump de sa mémoire vers le PC va te ressortir du langage machine.

Bonjour,

numero_744:
Y a-t-il un moyen de lire le programme uploadé ?

Oui, avec l'utilitaire avrdude et l'option -U flash:r:dump.hex:i (en utilisant le programmateur "arduino").

numero_744:
Ainsi, on pourrait savoir tout ce qui traine dans la mémoire flash, ce qui pourrait aider.

Ça n'aurait d’intérêt que dans le cas d'un "Reverse engineering", sinon dans le cadre d'une utilisation normale ça n'est d'aucune utilité.

numero_744:
De plus, on saurait comment le programme est enregistré dans la carte (sous quelle forme).

Binaire, sous forme d'opcode AVR8.
Au mieux tu peut décompiler le programme pour avoir son code source assembleur mais pas plus.
En aucun cas tu ne peut retrouver le code source C/C++ à partir du code assembleur.

numero_744:
Sinon, pourquoi la carte n'effacerait pas toute la flash au changement de programme ?

La carte efface systématique l'intégralité de la flash (excepté la partie bootlaoder) à chaque upload.
Si tu active le mode "verbeux" dans les options de l'ide arduino (case à cocher "upload") tu verras la commande "avrdude -e ..." qui efface la flash avant écriture.

@skywodd: concernant le dernier point de ta réponse je ne suis pas d'accord. Dans la flash on retrouve des morceaux d'ancien code. J'ai retrouvé des chaines constantes de programmes vieux de plusieurs mois en relisant la flash.

fdufnews:
@skywodd: concernant le dernier point de ta réponse je ne suis pas d'accord. Dans la flash on retrouve des morceaux d'ancien code. J'ai retrouvé des chaines constantes de programmes vieux de plusieurs mois en relisant la flash.

C'est bizarre ça ...
A part les ATxmega (qui fonctionne par pages mémoire) il me semble qu'un "chip erase" efface toute la flash (bootloader exclu) à chaque fois ...
Je ferai un essai pour voir :grin:

C'est sans doute une question de choix de configurateur dans l'appel à avrdude :

Page 12
Option -D
Disable auto erase for flash. When the -U option with flash memory is speci-
fied, avrdude will perform a chip erase before starting any of the programming
operations, since it generally is a mistake to program the flash without per-
forming an erase first. This option disables that. Auto erase is not used for
ATxmega devices as these devices can use page erase before writing each page
so no explicit chip erase is required. Note however that any page not affected
by the current operation will retain its previous contents.

De toute manière, le programme compilé sur l'eprom a une adresse de début et une adresse de fin et peu importe l'état des autres bits.

Pac2Kro:
et peu importe l'état des autres bits.

Elles sont pas toutes de ton avis XD

Up ou down XD