Comment déboguer un programme qui part n'importe où ?

Version imprimable

08/01/2016, 13h15
pcdwarf

Comment déboguer un programme qui part n'importe où ?

Bonjour,

J'aimerai savoir si il existe une façon de détecter le la collision stack / heap sur les AVR (plus précisément le atmega328 hyper utilisé pour les arduino.)
Je viens de passer 4 jours a trouver un bug (pointeur d'objet altéré par un débordement dans une interruption et l'appel de méthode qui fait n'importe quoi )
Le debugage a été épique : le crash n'avait pas du tout lieu à l'endroit de l'erreur.

A ma connaissance il n'est pas possible de lever une interruption sur invalidopcode ou sur un pointeur de stack hors limites.
mais peut-être qu'il y a des méthodes software qui permettent d'arriver au même résultat.

Quelqu'un a une piste ?
08/01/2016, 17h22
Vincent PETIT

Salut,
En effet, il n'y a pas de vecteurs d'interruption pour un stackoverflow

Citation:

Source Interrupt Definition (pour ton ATMEGA328P)
RESET External Pin, Power-on Reset, Brown-out Reset and Watchdog System Reset
INT0 External Interrupt Request 0
INT1 External Interrupt Request 1
PCINT0 Pin Change Interrupt Request 0
PCINT1 Pin Change Interrupt Request 1
PCINT2 Pin Change Interrupt Request 2
WDT Watchdog Time-out Interrupt
TIMER2 COMPA Timer/Counter2 Compare Match A
TIMER2 COMPB Timer/Counter2 Compare Match B
TIMER2 OVF Timer/Counter2 Overflow
TIMER1 CAPT Timer/Counter1 Capture Event
TIMER1 COMPA Timer/Counter1 Compare Match A
TIMER1 COMPB Timer/Coutner1 Compare Match B
TIMER1 OVF Timer/Counter1 Overflow
TIMER0 COMPA Timer/Counter0 Compare Match A
TIMER0 COMPB Timer/Counter0 Compare Match B
TIMER0 OVF Timer/Counter0 Overflow
SPI, STC SPI Serial Transfer Complete
USART, RX USART Rx Complete
USART, UDRE USART, Data Register Empty
USART, TX USART, Tx Complete
ADC, ADC Conversion Complete
EE, READY EEPROM Ready
ANALOG, COMP Analog Comparator
TWI, 2-wire Serial Interface
SPM READY, Store Program Memory Ready

Car ce n'est pas possible. Lorsque tu programmes en assembleur tu dois, toi même, initialiser la stack à l'adresse que tu souhaites, le reste de la RAM étant le heap. Avec un langage comme le C, c'est ton compilateur qui fait ce boulot mais dans tous les cas la vérification de la pile est une des choses que l'on doit vérifier lors de la phase de débug.

Et encore tu es chanceux, étant donnée que ton micro Atmel a une architecture Harvard (mémoire RAM sur un bus d'adresse/donnée différents de la mémoire programme) si la stack déborde trop au point de toucher le compteur programme (qui est empiler aussi lors de l'appel d'une fonction), elle va altérer la RAM et sortie de la fonction où tu étais tu vas te retrouver n'importe où dans ton programme. Si tu avais été sur un MSP430 de Texas qui a une architecture Von-Neumann (tout est sur les mêmes bus donc RAM puis Registres internes puis Mémoire programme dans la même continuité) si la stack déborde trop au point de toucher le compteur programme, elle va altérer la RAM ou des registres (Timer, ADC, GPIO) et sortie de la fonction où tu étais tu vas te retrouver n'importe où dans ton programme... alors là pour trouver ce qui se passe quand même le hard se met a faire n'importe quoi :aie: Par contre cette architecture à d'autres avantages, bref.

D'un point de vu soft tu n'as aucun moyen de voir ce qui se passe de manière sur car dit toi que à partir du moment où tu ajoutes une seule instruction dans le code, tu vas changer la nature du bug. Si tu as un débordement de pile qui, en plus d'altérer la RAM, vient modifier le compteur programme, si tu ajoutes une seule instruction quelque part alors au moment de la sortie de la fonction le compteur programme, ayant été modifié, alors tu vas sortir n'importe où dans le programme mais le fait d'avoir ajouté cette malheureuse instruction va peut être tout faire changer dans ce qui se passe et dans ce que tu vois. Pire encore tu pourrais même masquer le bug !

Atmel a une sonde de débug ATMEL ICE, à 80€ de mémoire, qui te permettra de faire des points d'arrêts, de dérouler le programme en pas à pas et de voir ce qui se passe dans tes registres en direct sous Atmel Studio (je n'ai pas de Atmel ICE mais je l'ai souvent fait avec la sonde de débug/prog Pickit de Microchip et aussi avec les solutions Texas Instruments comme le MSP-EXP430G2 où la sonde de débug est carrément sur la démo board). Un minimum de connaissance en assembleur peut aider aussi pour comprendre.

ps : Tu parles de méthode et d'objet, tu programmes ton micro en quel langage ?
09/01/2016, 00h47
pcdwarf

Bonjour,

merci pour ta réponse.
Ce que tu décris est exactement ce qui s'est passé mais pas pour la raison que j'ai cru.
ce n'était pas une collision heap/stack. C'était une (gigantesque) erreur d'adressage sur un tableau dans un objet statique (segment .bss) et ça conduisait à altérer la stack.

Par la suite, les retour de fonctions partaient n'importe où.
Le micro a même exécuté une fonction crée spécialement pour le debug et qui n'était appelée nulle-part.

Et accessoirement, ça a shooté l'eeprom en écrivant en boucle dedans.
Le fail complet quoi...

Citation:

du moment où tu ajoutes une seule instruction dans le code, tu vas changer la nature du bug.

C'est pour ça que j'ai mis tant de temps à trouver.... Et ce qui est énorme, c'est que ce bug s'est révélé suite a une modification mineure dans un module qui n'avait rien à voir avec l'emplacement de l'erreur. La version précédente (tout aussi monstrueusement buggée) tournait miraculeusement depuis plus de six mois.
Maintenant le vrai mystère c'est comment ça a pu fonctionner avant...

ps : j'ai programmé en C/C++ avec gcc-avr. Par contre, j'ai pas de programmateur "officiel" et c'est pourquoi je n'emploie pas atmel studio (accessoirement, je travaille pas sous windows).
existe-t-il d'autre soft pour le debuggage ?
J'ai un vieux pickit2 quelque part. tu as l'air de dire que c'est utilisable ? si oui, comment ?
Concernant l'assembleur, il y a 12 ans que j'en ai pas fait, et c'était sur 68hc11. J'ai une assez bonne compréhension du fonctionnement de l'ALU mais j'ai pas trop envie d'apprendre l'assembleur AVR. Rien que de pouvoir inspecter la ram à chaque breakpoint, ça doit pouvoir m'aider considérablement.
09/01/2016, 01h55
Vincent PETIT

Citation:

Envoyé par pcdwarf

Maintenant le vrai mystère c'est comment ça a pu fonctionner avant...

Oula, j'ai déjà eu des drôles de tour aussi, j'avais juste ajouté 1 malheureuse variable dans une fonction mais le problème c'est que j'avais trop de fonctions qui appelaient d'autres fonctions qui elles mêmes en appellaient d'autres... et ma stack était pleine lorsque toutes les fonctions étaient appelées et cette malheureuse variable a tout foutu en l'air car ma stack à fait : stack pleine + 1 variable a stocker et hop...... dans les choux. Je te crois sur parole quand tu dis "on cherche le bug un moment" mais là où j'ai été chanceux c'est sur la cause du problème, c'est à dire une seule variable en plus. Maintenant j'imagine même pas si j'avais changer une grosse partie du programme (du genre un coup je supprime du code, un coup j'en ajoute, ensuite je modifie des variables, j'en ajoute, je rechange et pas de bol à la fin de tout ça, ça fait 1 variable de plus à stocker par rapport à avant... et tout plante)

Citation:

Envoyé par pcdwarf

ps : j'ai programmé en C/C++ avec gcc-avr. Par contre, j'ai pas de programmateur "officiel" et c'est pourquoi je n'emploie pas atmel studio (accessoirement, je travaille pas sous windows).
existe-t-il d'autre soft pour le debuggage ?

Tout comme moi, je suis sous Debian 7 + Eclipse + GCC-AVR ou GCC-MSP430 + plugin Arduino ou plugin MSP430, ça dépend de ce que je fais. Malheureusement non, il n'y a rien à ma connaissance pour les ATMEGA328P hormis la sonde Atmel ICE. C'est pour cette raison que je me suis tourner vers Texas pour mes projets car eux, pas besoin de sonde si les bons composants sont implantés.

Citation:

Envoyé par pcdwarf

J'ai un vieux pickit2 quelque part. tu as l'air de dire que c'est utilisable ? si oui, comment ?

Excuse moi, je me suis affreusement mal exprimé ! Je voulais dire que j'avais souvent dégugger des micro, notamment PIC avec Pickit.

Citation:

Envoyé par pcdwarf

Concernant l'assembleur, il y a 12 ans que j'en ai pas fait, et c'était sur 68hc11. J'ai une assez bonne compréhension du fonctionnement de l'ALU mais j'ai pas trop envie d'apprendre l'assembleur AVR. Rien que de pouvoir inspecter la ram à chaque breakpoint, ça doit pouvoir m'aider considérablement.

Ok (on a appris l'assembleur sur le même dinosaure apparemment) mais ça ne sera peut être pas la peine car bien souvent ce problème est facile a résoudre une fois qu'on l'a détecté ! Visiblement, lorsque je lis ton message, je pense que tu n'as pas besoin de sonde car il te suffit de réintégrer le plus possible de fonction dans le programme principal. Vérifie les profondeurs d'appels : combien de fonction sont appelées de manière imbriquées et bien sur pas de fonctions récursives. Certes ça sera au dépend de la lisibilité mais ça va soulager la stack.

Ton programme est vraiment gros ? Je peux le voir ?

Bonjour.

Mon client ne voudrait probablement pas que je montre le programme à qui que ce soit mais je peux t'en mettre un extrait

Le programme n'est pas si gros que ça. il a été initialement fait pour le atmega88. mais il fallait vraiment tasser, c'était pas confort. et vu la différence de prix des µC.....

En gros le µC est un esclave modbus. (une version limitée de modbus rtu).
Les "adresses" 0 à X correspondent à des registres de "configuration" qui ne changent que très rarement. Pour économiser de la ram (on était vraiment à l'étroit sur le 88) Ils sont écrit en eeprom quand on en donne l'ordre et sont lu en eeprom à chaque fois que le programme en a besoin.

Pour les adresses plus grandes que X, ce sont de valeur variables qui sont stockées en ram dans un tableau statique. les adresses plus grande que ce tableau sont ignorées

voila la version buggée
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 #define ModbusRegistersEEPROMBaseAddr 0 #define ModbusRegistersEEPROMLastAddr 0x4F #define ModbusRegistersRAMBaseAddr ( ModbusRegistersEEPROMLastAddr +1 ) #define ModbusRegistersRAMLastAddr 0x7F uint16_t ModbusRegisters::Get16Reg(uint8_t addr) { if (addr > ModbusRegistersRAMLastAddr ) return 0xDEAD; // On a demandé une adresse invalide if ( addr <= ModbusRegistersEEPROMLastAddr ) return EEPROM.get16(addr); return Registers[addr-ModbusRegistersRAMBaseAddr]; } void ModbusRegisters::Set16Reg(uint8_t addr, uint16_t value) { if (addr > ModbusRegistersRAMLastAddr ) return; // On a demandé une adresse invalide if ( addr <= ModbusRegistersEEPROMLastAddr ) EEPROM.set16(addr, value); ///<<aie! Registers[addr-ModbusRegistersRAMBaseAddr] = value; ///<<aie! }
la fonction Set a été dérivée un peu trop rapidement de la fonction Get
(manque un else ou un return)

du coup, quand addr < ModbusRegistersRAMBaseAddr ,
Registers[addr-ModbusRegistersRAMBaseAddr] pointe n'importe où.
Probablement que la plupart du temps ça arrivait en dehors de la zone utilisée (peut être même en dehors des adresses où il y a physiquement de la ram) ***
(donc écriture en eeprom ok et pas de bug fonctionnel)
mais dans ma nouvelle version, ça altère la stack. et catastrophe...

Le crash en revanche se produisait très très loin de l'endroit du bug...
la difficulté a été de comprendre que l'altération était (très) loin du lieu du crash dans un bout de code réputé bon depuis des mois.

-----

*** : Je me demande si le décodeur d'adresse fait le modulo quand on sort de la plage où il y a physiquement quelque chose ou si ça ce contente d'écrire dans le vide?

D'accord, j'y vois plus clair.
Ta table MODBUS est faite comme ça :
Code:

1 2 EEPROM 0x00 à 0x4F RAM 0x50 à 0x7F
Suivant l'endroit à l'on veut écrire dans la table, au travers de la variable addr on sera soit en RAM soit en EEPROM

Effectivement comme tu le fais remarquer l'algorithme de Set16Reg est buggé est il provoque l'équivalent d'un SegmentFault, remonté d'un OS sur un PC.
Ici on a un simple débordement de tableau et comme tu l'as bien vu qui va aller foutre le bordel dans la RAM (qui contient entre autre la stack logicielle)
Code:

1 2 3 4 5 6 7 8 Si addr > 7F alors return car hors mémoire Si addr <= 0x4F (sous entendu compris entre 0 et 4F) alors EEPROM <- valeur RAM [addr - 0x50] <- valeur
Lorsque l'adresse à la quelle on veut écrire est inférieure à 0x4F alors on l'écrit dans l'EEPROM et aussi en RAM (sauf qu'en RAM on cause un débordement du tableau) imagine que l'adresse soit inférieur à 0x50 ? Alors l'index du tableau est négatif ! Donc a chaque fois qu'on écrit en EEPROM on fait un débordement de tableau.

La bonne solution est celle que tu dis : Ajouter un return
Code:

1 2 3 4 5 6 7 8 9 Si addr > 7F alors return car hors mémoire Si addr <= 0x4F (sous entendu compris entre 0 et 4F) alors EEPROM <- valeur return RAM [addr - 0x50] <- valeur
Donc ça, ça ne devrait plus buger.
Code:

1 2 3 4 5 6 void ModbusRegisters::Set16Reg(uint8_t addr, uint16_t value) { if (addr > ModbusRegistersRAMLastAddr ) return; // On a demandé une adresse invalide if ( addr <= ModbusRegistersEEPROMLastAddr ) return EEPROM.set16(addr, value); ///<<aie! Registers[addr-ModbusRegistersRAMBaseAddr] = value; ///<<aie! }
Mais depuis le début tu as la solution ? Pourquoi tu poses cette question du coup (comment débuger un programme qui part n'importe où) ?
A+

Bonjour.

En fait, non j'avais pas la solution depuis le début d'où ma question de collision stack/heap. alors qu'en fait c'est une erreur d'adressage
(en réalité je met le maximum de choses en statique pour que le compilo me calcule la taille du .bss mais j'ai du mal à évaluer l'utilisation de la stack et je n'avais aucune idée du niveau d'utilisation que j'en avais.)

Ce qu'il y a, c'est que j'ai perdu 4 jours de taf sur une ânerie de débutant et qu'un équivalent du seg-fault m'aurait bien aidé en bloquant le programme dès qu'il va écrire où il ne doit pas. (et aurait probablement permis de détecter la présence du bug dans les versions asymptomatiques.)

D'où ma question initiale : existe-il des méthodes (hard ou soft) pour détecter les gros craquages sur ce type ce CPU.
Apparemment la réponse est non.

Tu dis que c'est pas possible puisque on fixe soit même les zones de stack, heap etc... Oui. Mais on aurait pu imaginer des registres min/max avec lèvée d'interrupt si le pointeur de stack en sort. Idem pour une ecriture en ram.
Je n'ai rien vu de ça dans la doc mais j'aurais pu passer à coté.
Idem pour le invalid opcode (possible si on altère des pointeurs de fonctions). Je ne l'ai pas vu dans la doc mais apparemment ça reset le CPU sans lever aucun flag de MCUSR.

Pour ce qui est des methodes soft,
Je n'ai rien vu qui permette d'éviter ou de bloquer les grossières arreurs d'adressage comme j'ai pu faire avec mon tableau.

Mais j'ai trouvé des pistes pour évaluer l'usage de la ram.

J'ai dans l'idée qu'on peut balancer une alerte au heap trop gros (quand malloc renvoie une adresse trop grande et ensuite parquer le programme défaillant

ca donnerait quelque chose dans ce genre
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 void tropGourmand(void) { truc* ptr = (truc*) malloc( sizeof(truc) ); if ( ((void*)ptr) + sizeof(truc) > MaxHeapAddr ) oopsHeap(); // suite de la fonction... } void oopsHeap(void) { cei(); //inserer ici une ALERTE quelconque, genre allumage de led mais toujours un truc très simple. while(true); // le watchdog resetra le tout (ou pas) dans quelques secondes. }
peux tu me confirmer que l'idée est valide ?

pour repérer dans l'autre sens, j'ai aussi vu la technique du "canari" : remplir la ram avec une valeur spécifique et repérer jusqu'où la stack est allé en repérant les valeur altérées.
Mais c'est tout sauf transparent... et si ça permet de mesurer un programme fonctionnel, c'est potentiellement inapplicable si le programme crash déjà...

idem, que penses tu de l'idée...

Citation:

Envoyé par pcdwarf

[...]D'où ma question initiale : existe-il des méthodes (hard ou soft) pour détecter les gros craquages sur ce type de CPU.
Apparemment la réponse est non.

Je viens de voir que chez Texas, que je connais mieux que Atmel, ils ont MSP Debug Stack qui est apparemment un outil qui agit comme la sonde de débug pour voir ce qui se passe, d'ailleurs si j'ai bien compris ça passe même par la sonde (c'est un outil a intégré à l'IDE de Texas et qui n'est qu'un Eclipse déguisé) Il y a peut être les mêmes outils chez Atmel ? Après niveau soft même sur nos PC qu'ils soient sur Linux, Windows ou autres tu n'es pas à l'abri d'un débordement de tableau. On peut même s'estimer chanceux lorsqu'on le rencontre car au moins on sait qu'il y a un bug. Un segmentfault sur un OS c'est quand on veut aller à une adresse qui dépasse ce que l'OS a alloué pour notre programme mais si un débordement arrive et qu'il déborde dans le programme lui même alors tu ne vois rien du tout !
Exemple qui ne pose aucun soucis malgré un débordement de tableau :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 #include <stdio.h> int main (void) { char tab1[8]; char tab2[8]; tab1[0] = '0'; tab1[1] = '0'; tab1[2] = '0'; tab1[3] = '0'; tab1[4] = '0'; tab1[5] = '0'; tab1[6] = '0'; tab1[7] = '\0'; tab2[0] = 'B'; tab2[1] = 'o'; tab2[2] = 'n'; tab2[3] = 'j'; tab2[4] = 'o'; tab2[5] = 'u'; tab2[6] = 'r'; tab2[7] = '\0'; printf("Dans le tableau tab1 on a : %s\nDans le tableau tab2 on a : %s\n\n", tab1, tab2); tab2[8] = '?'; // j'affecte une valeur dans tab2 mais hors du tableau ! printf("Après un débordement volontaire de tab2\n"); printf("Dans le tableau tab1 on a : %s\nDans le tableau tab2 on a : %s\n\n", tab1, tab2); printf("La valeur de tab1 vient de changer alors que dans ce code je ne touche pas à tab1\n"); printf("J'ai simplement affecter une valeur dans tab2 mais hors du tableau et c'est tab1 qui a été affecté\n"); return 0; }
Citation:

Envoyé par pcdwarf

Tu dis que c'est pas possible puisque on fixe soit même les zones de stack, heap etc... Oui. Mais on aurait pu imaginer des registres min/max avec lèvée d'interrupt si le pointeur de stack en sort. Idem pour une ecriture en ram.
Je n'ai rien vu de ça dans la doc mais j'aurais pu passer à coté.
Idem pour le invalid opcode (possible si on altère des pointeurs de fonctions). Je ne l'ai pas vu dans la doc mais apparemment ça reset le CPU sans lever aucun flag de MCUSR.

Oui je suis d'accord c'était pourtant possible d'avoir un registre min/max pour la frontière stack/heap, la preuve est qu'avec le Timer c'est ce qu'on fait. J'ai tellement lu de doc de micro Microchip/Texas/Atmel/Motorola/NXP/ST que si ça existait je m'en rappellerai.
Pour l'opcode, je ne comprends pas trop ce que tu veux dire ? Pour moi un opcode c'est la valeur binaire d'une instruction assembleur (c'est la représentation binaire du jeu d'instruction qui fait tourner l'ALU du CPU)
Citation:
Envoyé par pcdwarf
Pour ce qui est des methodes soft,
Je n'ai rien vu qui permette d'éviter ou de bloquer les grossières erreurs d'adressage comme j'ai pu faire avec mon tableau.

Mais j'ai trouvé des pistes pour évaluer l'usage de la ram.

J'ai dans l'idée qu'on peut balancer une alerte au heap trop gros (quand malloc renvoie une adresse trop grande et ensuite parquer le programme défaillant

ca donnerait quelque chose dans ce genre
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 void tropGourmand(void) { truc* ptr = (truc*) malloc( sizeof(truc) ); if ( ((void*)ptr) + sizeof(truc) > MaxHeapAddr ) oopsHeap(); // suite de la fonction... } void oopsHeap(void) { cei(); //inserer ici une ALERTE quelconque, genre allumage de led mais toujours un truc très simple. while(true); // le watchdog resetra le tout (ou pas) dans quelques secondes. }
peux tu me confirmer que l'idée est valide ?
J'ai bien peur que ce ne soit très limité car ça peut te protéger d'une allocation supérieure au Heap mais imagine que tu fais un tout petit malloc (donc inférieure au MaxHeapAddr) et que le Heap est plein.
Alors la fonction ne le verra pas, puisqu'elle regarde simplement si le malloc est supérieure au MaxHeapAddr et ça va déborder. Il faudrait un truc plus complet mais infaisable à mon humble avis.

Il faudrait connaitre le % du heap qui est déjà occupé et ensuite regarder lors d'un malloc si la taille de celui-ci est comprise entre : le % du heap qui est déjà occupé et MaxHeapAddr !

Citation:

Envoyé par pcdwarf

pour repérer dans l'autre sens, j'ai aussi vu la technique du "canari" : remplir la ram avec une valeur spécifique et repérer jusqu'où la stack est allé en repérant les valeur altérées.
Mais c'est tout sauf transparent... et si ça permet de mesurer un programme fonctionnel, c'est potentiellement inapplicable si le programme crash déjà...

idem, que penses tu de l'idée...

C'est ce qu'un de mes ex-collègues faisait pour faire un check RAM mais je suis d'accord, si le programme a déjà planté alors ça ne fonctionne pas. Mais l'idée est intéressante en phase de conception du programme.

Lorsque j'étais professionnel dans ce domaine, je t'avouerai que je n'ai jamais trouvé de solution miracle pour me prévenir de ce genre de problème (débordement de tableau et débordement de la stack ou du heap.)
:fleche: Certain te diront qu'il y a moins de danger si la stack est initialisée après le heap (au fond de la RAM) comme ça la stack est contenu entre une certaine adresse et la fin de la mémoire. A essayer mais ça dépend aussi de l'architecture du micro. Pour Atmel c'est possible mais pas chez Texas en tout cas.

:fleche: Moi quand je code, j'essaye comme les développeurs en informatique, de faire super gaffe à tout ça : profondeur d'appelle, pas de récursivité indirecte, je compte l'emplacement mémoire quand je code par exemple dans une fonction je sais a peu près dire qu'elle place ça va prendre dans la pile, j'essaye de choisir un micro adapté, etc... Quand on est très prudent ça se passe souvent bien. Le pire étant les cas où le micro devient trop petit ou tu changes de cible.

10/01/2016, 11h08
pcdwarf

opcode => Il y a des zone de la flash qui contiennent des constantes. (des fontes pour ecran lcd par exemple)
Si le pointeur d'instruction arrive là dedans => il y a de fortes chances pour que la constante ne corresponde pas à une instruction assembleur valide.
et apparemment ça reset le cpu sans rien positionner dans MCUSR (parmi les causes de reset, il y a le watchdog, la pin reset, poweron, brownout... mais pas "gros bug")

Citation:

Moi quand je code, j'essaye comme les développeurs en informatique, de faire super gaffe à tout ça : profondeur d'appelle, pas de récursivité indirecte, je compte l'emplacement mémoire quand je code par exemple dans une fonction je sais a peu près dire qu'elle place ça va prendre dans la pile, j'essaye de choisir un micro adapté, etc... Quand on est très prudent ça se passe souvent bien. Le pire étant les cas où le micro devient trop petit ou tu changes de cible.

complètement d'accord : Je ne met *jamais* de récursivité ou alors sur un nombre de récursions déterministe, et connu comme très petit (2,3,4)...
Et j'essaie toujours d'employer la taille minimale pour les variables.

Citation:

Après niveau soft même sur nos PC qu'ils soient sur Linux, Windows ou autres tu n'es pas à l'abri d'un débordement de tableau.

Évidemment, mais tu sais si tu sors des pages allouées.

Apparemment tu développes sous linux aussi.
A part les AVR, quels sont les micro qu'on peut aisément programmer avec gcc/g++ ?
(et bien sur, il faut de quoi les flasher sans passer par un outil propriétaire. j'ai pas vu que avrdude ait un support pour les ARM.)
10/01/2016, 23h24
Vincent PETIT

2 pièce(s) jointe(s)

D'accord, je vois ce que tu veux dire par "opcode invalid", en effet chez Texas non plus il n'y a pas de protection si jamais le PC (Program Counter) s'en va sur une zone de la mémoire flash qui contiendrait non pas des instructions mais du stockage de données. Un des derniers projets sur le quel j'ai particité (car j'ai fait 90% du hard) c'était justement un capteur modbus et la table était en partie dans la RAM, pour ce qui bouge beaucoup, et le reste dans la mémoire flash, pour tout ce qui est réglage config etc... et c'est vrai que si par malheur le PC s'en va la dedans en pensant trouver des opcodes :aie: !!!!!

Chez Texas il y a une interruption "PC out of range" qui cause un reset mais ça ne laisse pas de trace dans aucun registre, tout comme toi avec le Status Register du Atmel.

Pour répondre à ta question, j'ai longuement hésité pour choisir un fabricant car d'une part je suis exclusivement sous Linux sans dual boot Windows et d'autre part je ne voulais pas investir trop d'argent dans l'outil de développement (j'ai plutôt investi dans mon oscilloscope.)

J'ai d'abord acheté un Arduino Uno à 30€, ATmega328P que je ne connaissais pas, et avec Eclipse + GCC-AVR + Avrdude c'était nickel car si je déportais le micro sur le montage réel je pouvais le programmer (en ne monopolisant pas les pins dédiées bien sur) mais je me suis rendu compte après coup qu'il n'était pas possible de faire du débug hardware sur cette plateforme et sur ce micro. La solution que j'ai envisagé, car 80€ c'était raisonnable, c'était d'acheter une sonde de débug Atmel ICE et la faire tourner avec le logiciel Avarice (et GDB-AVR) sous Eclipse.

Puis je me suis tourner vers Texas Instruments car au boulot nous avions des micro de ce fabricant. J'ai acheté une carte LaunchPad à 12€ (cette carte est semblable a Arduino sauf qu'elle contient le déboggeur Hard en plus du micro) donc plus besoin de sonde de débug comme Atmel ICE ou Pickit.

Pièce jointe 197644

Il me suffit de déporter le micro sur le montage réel pour pouvoir le programmer et le débugger en faisant dérouler le programme en pas à pas ou mettre des points d'arrêt et voir en direct l'état du micro : variable/registre/RAM. Mes outils sont Eclipse + GCC-MSP430 + MSPDEBUG (l'équivalent de Avrdude + Avarice) et 2 plugins pour Eclispe (le premier plugin gère à ma place toute la toolchain GCC-MSP + MSPDEBUG et je n'ai plus qu'a choisir la cible. Le second me sert a remonter tous les registres du micro pour voir ce qui se passe en direct)

Pièce jointe 197645

Sur cette image je suis en mode pas à pas et je vois mon programme en assembleur, mes registres CPU, mes registres périphériques, ma RAM, je peux aussi voir mes variables et connaître leur valeur en déroulant mon programme. Je suis encore en phase de test de ces outils et pour l'instant je vois tout ce que je veux. Bien sur dans mon travail on avait des logiciels propriétaires comme IAR et Keil qui coûtent la peau du ...

Un point important a prendre en compte. Chez Texas tous les micro n'utilise pas le même protocole de débug donc avec la LaunchPad qu'on voit en photo, je peux programmer toute une famille de MSP430 mais pas toutes. Si un jour je passe sur un autre micro dans une autre famille de chez Texas alors je devrai sûrement acheter une autre LaunchPad à quelque 10ene d'euros pour utiliser la sonde qu'il y a dessus.

Texas fournit gratuitement sons IDE Code Composer Studio, basé sous Eclipse pour Linux + 3 compilateurs : GCC-MSP430 (maintenu par Texas et Libre), celui de IAR je crois et celui de Texas (le propriétaire ce coup ci) par contre toutes les LaunchPad ne sont pas supporté sous Linux donc il faut faire attention lors de l'achat. J'ai une autre LaunchPad chez moi et avec un micro beaucoup plus gros (périphérique USB et tout le tralala) pour 15€ et celle ci est supportée sous Linux. Ah oui.... le seul soucis est que leur IDE a besoin d'un PC avec 4Go de RAM pour tourner correctement. Je n'y ai pas cru jusqu'à ce que j'essaye avec mon modeste PC et ces 2Go ! Effectivement c'est bien inutilisable avec 2Go de RAM !

Personnellement je préfère Texas Instruments car :
:fleche: Ils sont pro Linux.
:fleche: Ils fournissent très souvent leurs outils sur Window et Linux.
:fleche: Ils maintiennent CGG-MSP430 librement.
:fleche: Leurs docs sont beaucoup plus digestes que celles d'Atmel.
:fleche: Ils sont diversifiés, pas que des micros, ils font des composants logiques en plus de ce que fait Atmel.
:fleche: Leurs carte d'évaluation sont abordables http://www.ti.com/ww/en/launchpad/la...-msp.html#tabs

Inconvénients :
:fleche: Très présent chez les professionnels mais alors suasi inexistant chez les particuliers et amateurs (ils ont sortie Energia qui est un fork de Arduino pour se faire connaître aux makers)
:fleche: Beaucoup moins de tuto sur le net si je compare à Microchip et Atmel et pas beaucoup de littérature française sur l'animal !

Concernant les micro ARM ils en ont chez Texas et dans le même esprit le debuggeur Hard est implanté sur la LaunchPad du MSP432 - ARM Cortex M4F (13$) donc si on déporte le micro sur le montage réel alors la LaunchPad devient une sonde de débug (valable aussi pour les micros de la même famille utilisant le même protocole de débugage)

Prochaine étape, lorsque je maîtriserai les outils, me passer des plugins ou trouver le moyen d'élargir leurs limites :
- J'aimerai que le premier plugin ne m'enferme pas dans la très grande famille des MSP430 (µC 16 bits) mais qu'il m'ouvre les portes des MSP432 (µC ARM)
- Je vais essayer de comprendre comment fonctionne le second plugin qui sert a remonter l'état des registres du micro (je pense qu'en réalité ce plugin ne sert qu'a rendre compréhensible en mettent en forme des données déjà connu par l'IDE ou MSPDEBUG)
11/01/2016, 00h28
pcdwarf

Je note Avarice. Je ne connaissait pas.
En fait je n'emploie pas d'IDE. La plupart m'ont fait tourner en bourrique assez rapidement.
L'est un peu old-school mais généralement un simple éditeur texte avec analyse de syntaxe dans le genre de Gedit me suffit amplement.

Pour revenir aux micros Texas, je ne les connais pas mais tout ce que tu m'en dis me parait très séduisant. (en plus c'est du 16 bits)
Le peu de support communautaire n'est pas un vrai problème.
A vrai dire, la quantité de noobs qui se mettent aux arduino sans avoir jamais écrit une ligne de C et se sentent autorisé à donner des conseils dès qu'ils ont fait clignotter une led est un reel problème quand on cherche des infos.

Seul point, je suis très attaché à la programmation in situ, et si possible, sans avoir besoin d'électronique dédiée (Dans la plupart de mes circuits, les microcontroleurs n'effectuent que des tâches bas niveau et sont relié à un truc plus musclé genre raspberryPI qui les programme directement avec des gpio, c'est plus lent que la plupart des autres programmateurs, mais c'est très pratique). pour les MSP430, de ce que j'ai pu lire (en diagonale) mspdebug a besoin d'une interface jtag ? des conseils dans ce domaine ?
11/01/2016, 01h12
Vincent PETIT

Citation:

Envoyé par pcdwarf

Je note Avarice. Je ne connaissait pas.
En fait je n'emploie pas d'IDE. La plupart m'ont fait tourner en bourrique assez rapidement.
L'est un peu old-school mais généralement un simple éditeur texte avec analyse de syntaxe dans le genre de Gedit me suffit amplement.

C'est pareil pour moi mais j'ai eu le malheur de goûter à IAR (un IDE bien fait) ou encore MPLAB où tu vois tout dans le même IDE. Du coup refaire marche arrière comme je le faisais avant ça me freine un peu !

Citation:

Envoyé par pcdwarf

Pour revenir aux micros Texas, je ne les connais pas mais tout ce que tu m'en dis me parait très séduisant. (en plus c'est du 16 bits)
Le peu de support communautaire n'est pas un vrai problème.
A vrai dire, la quantité de noobs qui se mettent aux arduino sans avoir jamais écrit une ligne de C et se sentent autorisé à donner des conseils dès qu'ils ont fait clignotter une led est un reel problème quand on cherche des infos.

:D je vois ce que tu veux dire.
Concernant Texas, c'est plus ce qu'il y a autour que je préfère car toi et moi savons que le micro en lui même, d'un fabricant à un autre c'est quasiment pareil (on a toujours un registre de direction pour les I/O, on a toujours un flag quand un octet est partie de l'UART, les timers fonctionnent de la même manière, etc...) La ressemblance entre les registres des AVR et MSP est même forte.

Citation:

Envoyé par pcdwarf

Seul point, je suis très attaché à la programmation in situ, et si possible, sans avoir besoin d'électronique dédiée (Dans la plupart de mes circuits, les microcontroleurs n'effectuent que des tâches bas niveau et sont relié à un truc plus musclé genre raspberryPI qui les programme directement avec des gpio, c'est plus lent que la plupart des autres programmateurs, mais c'est très pratique). pour les MSP430, de ce que j'ai pu lire (en diagonale) mspdebug a besoin d'une interface jtag ? des conseils dans ce domaine ?

Pour MSPDEBUG en effet il a besoin d'une interface Jtag, donc une sonde dans le genre du Pickit ou encore de la sonde Atmel ICE. Mais si tu regardes bien la photo de la carte électronique rouge, tu peux voir le micro (format DIP) et au dessus il y a des composants CMS et bien elle est là l'interface JTAG. Côté PC, une fois le câble USB branché cette carte est vue comme un port série virtuel et côté micro il pense voir une interface JTAG (une sonde de débug) au protocole SBW "spy by wire" aussi appelé 2 wires JTAG. Par contre tous les micro Texas ne se programme pas avec le SBW car au fur est à mesure, des améliorations arrivent et ils sortent des trucs de plus en plus performant comme EnergyTrace ou autre....
ATTENTION donc, si tu prends TI, de faire attention à la carte qu'il te faut.

Donc tu peux :
Retirer le micro de la carte rouge (il est monté sur support tulipe) et avec des simples fils tu viens te relier au vrai micro de ton vrai montage. La carte rouge en photo ne te sert que de sonde JTAG !
Précaution => il faudrait que je regarde le schéma pour te dire combien de fil sont nécessaires et qu'elles brochent du micro sont monopolisées.

Je ne sais pas si j'ai été clair sur l'avantage de ça ?

En tout cas, je n'essaye pas de te vendre TI c'est juste que j'ai essayé ATMEL et j'ai vu que je ne pouvais pas débugger sans sonde alors qu'avec TI je peux sans gros investissement.
12€ la carte rouge et la sonde JTAG est dessus mais limitée à certain de micro qui utilise le même protocole contre 80€ pour l'Atmel ICE qui est une vraie sonde JTAG et fonctionnelle pour toute la gamme ATMEL cette fois ci !

ps : se servir de MSPDEBUG (donc avancer le programme pas à pas, mettre un point d'arrêt dans le programme etc...) sans IDE comme Eclipse je ne sais pas le faire, il faudrait que je regarde. Moi aujourd'hui dans Eclipse j'ai un bouton "STEP" et quand je clique dessus l'IDE surligne la ligne de code suivante, il l'exécute et me donne l'état de mes registres + variables !
Au vu des projets que tu fais, je pense qu'un moyen de pouvoir débugger en pas à pas et voir ce qui se passe en live ne serait pas du luxe !