ATmega328P-PU 8Mhz 3.3V qui ne veut pas se laisser programmer

Bonjour à tous

Avez-vous déjà eu ça??

Habitué aux montages ATmega328P-PU sur breadboard en 8MHz interne et en 3.3V, je me casse les dents depuis plusieurs jours sur les derniers µ reçus. Ils ne se laisse pas programmer via un FTDI.

Je m’explique: J’achète des µ sans bootloader, je fais des montages sur circuit imprimé. Je charge le bootloader 8MHZ/3.3V via une carte UNO en ISP et un shield maison équipé d’un ZIF 28 pattes. Ensuite, je televerse le programme dans le µ via un FTDI sur le montage finalisé. Le processus est rodé, j’ai déjà fait une douzaine de montages de ce genre. Voulant en faire d’autres, j’ai acheter 10 ATmeg328P-PU (j’insiste sur P-PU, bien que j’ai déjà fait ça sur des -PU) chez des marchants renommés du web en composants électroniques (RS et F*4). Je me retrouve confronté au problème suivant: je peux charger le bootloader via ISP mais impossible de televerser via FTDI. Par contre je peux téléverser le sketch via ISP en téléversant par programmateur (mais sur shield avec ZIF). J’ai bien sûr vérifié mes soudures sur CI. Pour finir, j’ai échangé ces µ par des anciens déjà en ma possession (avec 6 exemplaires) tout se passe sans encombre en téléversant via FTDI. Si je remets les µ récents (j’ai testé les 10), impossible (réponse AVRdude :not in sync: resp=0x60)

Est-ce que quelqu’un a déjà eu ce problème? Je sèche sur le fil à linge…

Merci pour vos réponses

Bonjour,
La signature des deux composants sont différentes. ce paramètres ne devraient poser problème que lors de la programmation ISP.
Or ici l'ISP fonctionne.

Quelle type de carte avez vous sélectionner dans l'IDE?

Il faudrait faire un essai avec un autre type de carte daans l'IDE pour voir ce que ça donne.

La signature du -PU est 0x14, celle du P-PU est 0x0F. Les "anciens achetés" P-PU que je peux téléverser via FTDI et les "nouveaux achetés" ont bien la même signature 0x0F.
je sélectionne AVRISP mkII et "ATmega328P sur une breadboard (8MHz horloge interne)" que j'ai rajouté dans le board.txt avec les données suivantes:

atmega328bb.name=Atmega328P sur une breadboard (8 MHz horloge interne)
atmega328bb.upload.protocol=arduino
atmega328bb.upload.maximum_size=30720
atmega328bb.upload.speed=57600

atmega328bb.bootloader.low_fuses=0xE2
atmega328bb.bootloader.high_fuses=0xDA
atmega328bb.bootloader.extended_fuses=0x05
atmega328bb.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb.bootloader.unlock_bits=0x3F
atmega328bb.bootloader.lock_bits=0x0F

atmega328bb.build.mcu=atmega328p
atmega328bb.build.f_cpu=8000000L
atmega328bb.build.core=arduino:arduino
atmega328bb.build.variant=arduino:standard
atmega328bb.bootloader.tool=arduino:avrdude
atmega328bb.upload.tool=arduino:avrdude

J'ai tenté avec "Arduino Pro or Pro mini", mais c'est pas mieux.

il faudrait bien essayer de programmer le bootloader en sélectionnant la carte "Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328P" (pas seulement essayer de programmer en FTDI).
Je vois que les fuses sont un peu différent, mais je n'ai pas regardé quels sont les écarts.

pro.menu.cpu.8MHzatmega328.bootloader.low_fuses=0xFF 
pro.menu.cpu.8MHzatmega328.bootloader.high_fuses=0xDA 
pro.menu.cpu.8MHzatmega328.bootloader.extended_fuses=0xFD

Est-ce que tu as une capa de 0.1uF sur la ligne DTR?

Bonjour,

Oui, j'ai une capa sur le DTR. Pour la valeur du fuse bootloader.low, à 0xE2, cela fonctionne avec les 6 exemplaire

je disais... avec les 6 exemplaires achetés précédemment. J'ai essayé le bootloader du Pro or Pro mini, mais c'est le même symptôme. Pour info , AVRdudeSS me trouve la signature en détection à 0x0F (c'est donc bien des P-PU)

vite comme ça, je dirais; au rebut (pour ne pas être grossier) le FDI et utilise la méthode from scratch style RESET / MOSI / MISO / SCK avec un programmer Arduino as ISP.

Je fais ça avec toutes les IC d'Atmel, peu importe lequel, ça marche. Ça évite les intermédiaires USB merdiques propres à toutes sortent d'ordinateurs merdiques et donc, les problèmes de compatibilité.

Bonjour, merci pour les réponses.

La méthode par programmateur ISP est très contraignante lorsque l'on doit faire une calibration du sketch et de menues adaptations: les pattes du µ ont du mal à supporter les insertions/extractions de son support 28 broches. Si je ne trouve pas de solution, je continuerais effectivement par le biais de l'ISP.

@JCB26 Salut, je me demandais c'était quoi une calibration du sketch et menues d'adaptation?

J'avais une question.. Si j'ai à laisser l'option de hacker un montage Arduino, est-ce qu'il est mieux de laisser l'option SPI (miso mosi etc..) ou plutot celle du FTDI (tx/rx)?

Bonjour TTTTT

Quand je mets au point un montage , je modifie des paramètres, des tempos, un calcul, ou je travaille avec un capteur, par exemple, qui va faire des mesures d'une entrée analogique avec 1023 niveaux qui sont fonction de la tension d'alimentation précise du µ (si je ne prends pas la référence du 1.1V) je téléverse 10, 20 ,30 fois le sketch pour prendre en compte les modifs, ou mettre au point une fonction particulière. Si j'utilise un programmateur ISP, c'est lourd! Alors qu'avec un FTDI, on programme via le tx/rx, ce qui est équivalent à téléverser vers un Arduino classique et on peut utiliser la sortie série pour déboguer le programme. J'espère que ça répond à tes questions.