Jump to content
Sign in to follow this  
F1EQA

Programmation µP ATMEL

Recommended Posts

F1EQA

Bonjour a tous

Pour une réalisation d'un VFO j'ai besoin de programmer un µP ATMEL à partir d'un fichier .HEX .J'ai fait des essais a partir de AVRDUDESS mais je rencontre des difficultés dans l'utilisation de ce logiciel.

Y a-t-il des utilisateurs de ces µP sur ce forum qui pourraient m'aider ?

Michel F1EQA

Share this post


Link to post
F4HTQ

Bonjour Michel,

Décrivez précisément jusqu’à ou vous êtes arrivé et détaillez le problème que vous rencontrez.

Ainsi que le matériel que vous utilisez ( programmateur pour le microcontrôleur), modèle du microcontrôleur, et origine du fichier HEX.

Je n'utilise pas personnellement AVRDUDESS mais directement AVRDUDE en ligne de commande, mais c'est peut être indépendant de votre problème.

David.

Share this post


Link to post
F1EQA

Bonjour David

J'ai

-un fichier .HEx venant de la compilation d'un programme écrit avec BASCOM par ZL2PD ( VFO Multifonction)

- Un programmateur USBTINY...

-AVRDUDESS que j'ai du mal à utiliser.

L'écriture dans le µP ( Atmega 328P) donne des erreurs

Je ne trouve pas le fichier lors de la lecture du µP !

C'est la première utilisation de µP de cette marque que je tente.

Michel

Share this post


Link to post
F1EQA

Detected 1e950f = ATmega328P

si5351VFOv11.hex: 0 / 32 768 Bytes (0,00%)
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "C:\Radio\SI5351\ZL2PD\ZL2PD_si5351VFOv11 (2)\si5351VFOv11.hex"
avrdude.exe: input file C:\Radio\SI5351\ZL2PD\ZL2PD_si5351VFOv11 (2)\si5351VFOv11.hex auto detected as Intel Hex
avrdude.exe: writing flash (15444 bytes):
Writing | ################################################## | 100% 43.80s
avrdude.exe: 15444 bytes of flash written
avrdude.exe: verifying flash memory against C:\Radio\SI5351\ZL2PD\ZL2PD_si5351VFOv11 (2)\si5351VFOv11.hex:
avrdude.exe: load data flash data from input file C:\Radio\SI5351\ZL2PD\ZL2PD_si5351VFOv11 (2)\si5351VFOv11.hex:
avrdude.exe: input file C:\Radio\SI5351\ZL2PD\ZL2PD_si5351VFOv11 (2)\si5351VFOv11.hex auto detected as Intel Hex
avrdude.exe: input file C:\Radio\SI5351\ZL2PD\ZL2PD_si5351VFOv11 (2)\si5351VFOv11.hex contains 15444 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 21.31s
avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0400
0x80 != 0x8f
avrdude.exe: verification error; content mismatch
avrdude.exe done. Thank you.
Le programmateur est une copie chinoise

Share this post


Link to post
F4HTQ

Alors la.... ça va pas être évident.

Apparemment vous avez correctement fait les choses.

La platine est une platine arduino ou alors c'est une platine montée par vous-même ?

Vous pouvez aussi copier coller sur le forum la ligne de commande envoyé a avrdude ?

C'est quel programmateur exactement que vous utilisez ? si il a été acheté sur ebay, vous pouvez mettre le lien vers l'annonce ?

Edited by ALLOZA David

Share this post


Link to post
F5OWL

Bonjour,

Je vois que vous utilisez windows mais je pense que j'ai eu quasiment le même problème avec avrdude sous linux.

avrdude.exe: Device signature = 0x1e950f  :

c'est bien la signature de l'ATMEGA 328P donc le câblage est correct.

avrdude.exe: writing flash (15444 bytes):



Writing | ################################################## | 100% 43.80s



avrdude.exe: 15444 bytes of flash written  

avrdude pense avoir écrit correctement votre fichier hex en flash.

avrdude.exe: reading on-chip flash data:



Reading | ################################################## | 100% 21.31s


avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0400
             0x80 != 0x8f
avrdude.exe: verification error; content mismatch

Mais la vérification (relecture de la flash et comparaison avec le fichier original) ne passe pas.

Vérifiez aussi à l'oscillo que la tension d'alim et la tension de programmation restent bien stable pendant la totalité de la manip. C'est peut être un défaut du programmateur.

Refaite la manip plusieurs fois. Si l'erreur se produit toujours à la même adresse (ici 0x0400) (*) c'est probablement que la mémoire flash de votre composant

à un problème à cette adresse =>mettre l'ATmega à la poubelle (ou au recyclage pour être politiquement correct).

Si l'erreur se produit à des adresses différents c'est probablement un problème de buffer overflow dans le driver. En effet à l'écriture c'est le pc qui envoie les données à son rythme et le programme et l'atmega les acceptent.

A la vérification le programmateur envoie les données au PC peut être trop rapidement. C'est ce que j'en ai conclu car même avec cette erreur mon programme marchait et si je change de pc ( et utilise une version de linux plus récente) ça marche parfaitement.

Si c'est bien ça, essayez avec un programme très court, ça devrait passer sans problème. Je n'ai pas vraiment trouvé de solution à ce problème, je change juste de pc.....

Vous pouvez aussi vérifier les "fusibles" de l'atmega en vous connectant directement dessus avec l'option -t : (avrdude -c UsbTiny -p ATmega328p -t ). Ensuite vous pouvez dumper les différents mémoires (voir la doc de avrdude)

73

Philippe

(*) : 0x0400 c'est un adresse "ronde'". Y a pas un problème de zone interdite en écriture ? Je ne connais pas trop ces aspects sur les AVR.

Edited by F5OWL

Share this post


Link to post
F4HTQ

...

(*) : 0x0400 c'est un adresse "ronde'". Y a pas un problème de zone interdite en écriture ? Je ne connais pas trop ces aspects sur les AVR.

Bonjour Philippe,

C'est en plein milieu de la SRAM (sur un 328 ), donc dans un endroit ou on a le droit d'écrire.

atmega10.gif

David.

Edited by ALLOZA David

Share this post


Link to post
F1EQA

J'utilise une carte arduino pour "planter" le µP et son interface ICSP vers le programmateur.

Je vais tester les alims et faire des essais répétés pour voir si l'erreur est toujours la même !

Les µP viennent de chez RS ,des gens sérieux je pense.

Share this post


Link to post
F1EQA

Après plusieurs essais:

- mismatch 0x0000 0xff!=0x8f

- mismach 0x0000 0x80!=0x0c

Je vais changer de machine, mais il faut tout réinstaller !

Share this post


Link to post
F4HTQ

Je viens de regarder, il me reste 5 Atmega 328P en boitier DIP.

Au pire, si vous ne vous en sortez pas, vous m'indiquez ou se trouve le fichier HEX sur le net, et je vous en flashe un, je le met dans une enveloppe et vous l'avez deux jours plus tard.

Share this post


Link to post
F5OWL

Bonjour David,

C'est en plein milieu de la SRAM (sur un 328 ), donc dans un endroit ou on a le droit d'écrire.

Pas d'accord. C'est une architecture de harvard. Il y a deux plans mémoires séparés un pour la flash et un autre pour la RAM.

La RAM va de 0x0000 à 0x08FF avec le début pour les registres (avant 0x0100). Dans la RAM on pourrait écrire mais ce n'est l'endroit pour le programme.

Les 32k de flash sont entre 0x0000 et 0x3FFF (sur 16bits).

Sur le log avrdude dis bien :

avrdude.exe: reading on-chip flash data:

Donc 0x0400 c'est bien dans la flash.

Ma question était de savoir s'il y avait des zones protégeables par fusible dans la Flash comme c'est le cas pour certains pic.

Dans ce cas ça aurait pu expliquer l'impossibilité de programmer à partir de 0x0400.

Un relecture rapide de la doc semble me dire que non. Sauf pour les zones bootloader

mais qui sont bien plus haut dans la mémoire.

Philippe

Share this post


Link to post
F5OWL

Bonjour Michel,

Si vous utilisez une carte arduino vous pouvez déjà essayer de flasher le bootloader (dans arduino outils->Graver la séquence d'initialisation) et de voir

si vous obtenez un arduino utilisable; ça lèvera le doute sur le programmateur et le micro.

(Ici la procédure pour linux : http://arlotto.univ-tln.fr/arduino/article/charger-le-bootloader-avec )

J'ai les même programmateurs mais ce sont des fabrications bas de gamme, on ne peut pas exclure un défaut.

Philippe

Edited by F5OWL

Share this post


Link to post
F1EQA

J'ai rechargé le fichier .HEX et maintenant la vérification est bonne ! C'est le fichier qui était anormal ?

Bon il reste a voir si le µP est bien programmé et si cela fonctionne.

Pour le moment je remercie Daniel et Philippe du temps qu'ils m'ont consacré.

Michel

Share this post


Link to post
F4HTQ

Ok pour les 2 plans mémoire, ça m'avais échappé.

Par contre:

Bonjour David,..

Les 32k de flash sont entre 0x0000 et 0x3FFF (sur 16bits).

..Philippe

On ne peut adresser que des adresses paires ?

ça me semble un peu bizarre que les adresses ne soient pas exprimées en octets, c'est pas courant, et ça peut être une belle source de bugs pour ceux qui font de l'arithmétique de pointeurs dans leur code.

David.

Edited by ALLOZA David

Share this post


Link to post
F5OWL

Ok pour les 2 plans mémoire, ça m'avais échappé.

Par contre:

Bonjour David,..

Les 32k de flash sont entre 0x0000 et 0x3FFF (sur 16bits).

..Philippe

On ne peut adresser que des adresses paires ?

ça me semble un peu bizarre que les adresses ne soient pas exprimées en octets, c'est pas courant, et ça peut être une belle source de bugs.

David.

Toutes les instructions sont sur 16 ou 32 bits. En général on n'écrit que des instructions dans la flash.

Si on a des constantes à y écrire il doit y avoir des contraintes d'alignement. Je n'ai pas regarde le détail

car je n'ai fait que du C sur ce micro. Avec le mot clé PROGMEM ça va en flash et ça se débrouille.

Share this post


Link to post
F4HTQ

Bon, j'ai vérifié (avec le simulateur AVR qui est embarqué dans AtmelStudio, sur du code C, le tout compilé avec le GCC).

Au niveau des pointeurs (stockés sur 16 bits) , ils expriment des adresses en octet, donc pas de particularités.

Donc une soustraction de pointeurs donnera une taille en octets, et les pointeurs vers la flash irons jusqu'a la valeur 0x7FFF.

Au niveau des alignements, si je met mes datas ( initialisées ) dans la flash, il aligne le début du symbole sur une adresse paire ( en gros il faut du padding entre deux tableaux de char consécutifs si le premier n'a pas de longueur paire).

Donc rien de particulier au niveau du modèle de programmation, c'est l'usage d'aligner les adresses mémoire sur la taille d'un mot du processeur ( ici 16 bits)

Sachant que ce n'est pas une particularité de la couche C ou C++, si je regarde l'assembleur généré il gère la aussi des adresses exprimées en octet pour aller lire dans la flash.

Edited by ALLOZA David

Share this post


Link to post
F4HTQ

J'ai rechargé le fichier .HEX et maintenant la vérification est bonne ! C'est le fichier qui était anormal ?

Bon il reste a voir si le µP est bien programmé et si cela fonctionne.

Pour le moment je remercie Daniel et Philippe du temps qu'ils m'ont consacré.

Michel

Bonsoir Michel,

Content que vous y soyez parvenu. :)

Je vous conseille de mettre de coté ce microcontrôleur pour votre montage, et de ne pas tenter de le re-programmer si ce n'est pas indispensable. Car vous arriverez surement à l'effacer, mais pas forcement à le re-programmer.

Je ne pense pas que le fichier y soit pour grand chose, même si ce n'est pas impossible, ça serait quand même assez étonnant.

Je pense plutôt que vous avez un soucis au niveau de la configuration de votre matériel et que parfois ça marche mais souvent ça ne marche pas (c'est l'erreur qui ne tombe jamais au même endroit qui m'incite à penser ça).

Je vous souhaite moins de complications pour la suite :)

David.

Edited by ALLOZA David

Share this post


Link to post
F1EQA

Bonjour

OK je vais garder soigneusement celui là pour les premiers essais du montage. La question se reposera car il y a des modifications a faire dans les fréquences. Il me reste a trouver un logiciel BASCOM pour cela , la version Démo ne suffisant pas.

Merci pour le moment, et peut-être a plus tard

Michel F1eqa

Share this post


Link to post
F1EQA

F1EQA de retour !

Toujours de soucis ! Il y a trop d'inconnues dans mon montage !

Pour en éliminer la principale je vais souscrire a la proposition de Daniel qui proposait de me programmer un µP.

Bonjour a tous

Michel

Share this post


Link to post
F4HTQ

Bonjour Michel,

Il me faut quelques informations:

Pour commencez, préférez vous un atmega 328 tout seul ou un clone d'arduino nano ? ( j'en ai une poignée en stock, ça s’achète au alentours d'un euro pièce sur ebay, soit moins cher que le timbre pour vous l'envoyer :lol: ).

Il me faut connaitre les "fuses", c'est à dire savoir par exemple si le microcontroleur utilisera un quartz externe, ou si ce n'est pas le cas, à quelle fréquence il doit fonctionner.

Il me faut savoir ou télécharger le HEX à programmer. Un lien vers un descriptif de ce que fait le programme pourrait aider.

Et ça devrait être tout, dans un premier temps.

Si je m'en sort je vous demanderais alors votre adresse ( par MP ) pour vous l'envoyer.

David. ( et non Daniel).

Share this post


Link to post
F1EQA

OK David

Ce n'est pas pour un Arduino

Il suffit d'aller sur le site de ZL2PD et de regarder la rubrique Flexible SI5351 HF VFO/BFO.

Le fichier est a télécharger vers la fin ZL2PD_SI5351vfoV11.zip.

Il y a également ke détail des fusibles.

Share this post


Link to post
F4HTQ

ok Michel,

J'essais de m'en occuper ce week end.

David.

Share this post


Link to post
F1EQA

Rien ne presee !

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  

×
×
  • Create New...