Hallo zusammen, beziehe regelmässig 328p Boards aus China, die ich per avrdude (Raspbian) über einen Bootloader via USB flashe - immer bestens - ohne Probleme. Regelmässig muss ich zuvor bei den Fuses die CHDIV8 zurücksetzen. Jetzt habe ich eine Serie erwischt, die zwar per Booloader flasbar sind, aber sich via ISP (vom STK500) nicht ansprechen lassen. Über den Bootloader lassen sich die Fuses bekanntlich nicht lesen / modifizieren. Also will ich es per HVP (PP) versuchen. Das 328p Board lässt sich aber nicht auf das STK500 Board aufstecken, also muss ich mir einen Adapter bauen. Nun meine eigentliche Frage: Welche PINs vom 328P müssen mit dem STK500 für HVP (PP) verbunden werden? Im Datenblatt des 328p finde ich hierzu keine Hinweise. Wo bitte bei MicroChip kann ich hierzu die Definitionen nachlesen? Hat jemand bitte einen Link für mich? Danke & Gruesse
Hendrik L. schrieb: > Im Datenblatt des 328p finde ich hierzu keine Hinweise. Vllt. suchst du an der falschen Stelle. HV Programmierung heisst im Datenblatt 'Parallel Programming' und findet sich in der Abteilung Memory Programming. Im aktuellen Datenblatt ist das Kapitel 28.6
Matthias S. schrieb: > Hendrik L. schrieb: >> Im Datenblatt des 328p finde ich hierzu keine Hinweise. > > Vllt. suchst du an der falschen Stelle. HV Programmierung heisst im > Datenblatt 'Parallel Programming' und findet sich in der Abteilung > Memory Programming. > Im aktuellen Datenblatt ist das Kapitel 28.6 Super Hinweis - Vielen Dank. Beantwortet meine Frage sogar mit Schaubild. Schade dass die Suche nach HVP beim 328p in der Doku nicht in dieses Kapitel führt ...! Bei meiner (neuesten Ausgabe) übrigens in Kapitel 31 ff. Gruesse
Hendrik L. schrieb: > Bei meiner (neuesten Ausgabe) übrigens in Kapitel 31 ff. Ich habe das Datenblatt vor ein paar Minuten von Microchip geladen :-O Aber ist ja wurscht, wenn du es gefunden hast.
Matthias S. schrieb: > Hendrik L. schrieb: >> Bei meiner (neuesten Ausgabe) übrigens in Kapitel 31 ff. > > Ich habe das Datenblatt vor ein paar Minuten von Microchip geladen :-O > Aber ist ja wurscht, wenn du es gefunden hast. Upps - hatte mir zwar heute auch eins geladen ... bin aber beim Browsen im Filesystem bein einer Version mit Download Datum 9.9.2017 gelandet - sorry for confusion. Deckblatt zeigt: 8-bit AVR Microcontrollers ATmega328/P DATASHEET COMPLETE und hat 441 Seiten Das von heute lautet ATmega328P 8-bit AVR Microcontroller with 32K Bytes In-System Programmable Flash DATASHEET hat 293 Seiten Danke & Gruesse
Hendrik L. schrieb: > Bei meiner (neuesten Ausgabe) übrigens in Kapitel 31 ff. Keine Ahnung was Du da tatsächlich erwischt hast? Wenn es 32 oder 33 gewesen wäre, dann wär es wenigstens eine der PB Versionen. Hendrik L. schrieb: > Das von heute lautet > > ATmega328P > 8-bit AVR Microcontroller with 32K Bytes In-System > Programmable Flash > DATASHEET > > hat 293 Seiten Wo kommt das nun wieder her? Bei dem gerade von mir geladenen steht als Titel "ATmega48A/PA/88A/PA/168A/PA/328/P", ist vom 1.11.18 und hat 662 Seiten: https://www.microchip.com/wwwproducts/en/ATMEGA328P
guest schrieb: > ist vom 1.11.18 und hat 662 > Seiten Das ist das, aus dem ich meine Infos gezogen habe. Kann sein, das der TE den Waschzettel für die Automotive Version erwischt hat?
Matthias S. schrieb: > Kann sein, das der TE > den Waschzettel für die Automotive Version erwischt hat? Von dem 328P gibt es gar keine Automotive Version, nur vom PB, da wär es dann Kapitel 33 und das Teil hat 460 Seiten (10.07.2018)
Hendrik L. schrieb: > Über den Bootloader lassen sich die Fuses bekanntlich nicht lesen / > modifizieren. Sagt wer ?
Marc V. schrieb: > Hendrik L. schrieb: >> Über den Bootloader lassen sich die Fuses bekanntlich nicht lesen / >> modifizieren. > > Sagt wer ? Probier's 'mal aus ...! Here we go (zuerst einmal lesen, um zu zeigen, dass der 328p prinzipiell erkannt wird ... und dann der Versuch des Schreibens ... root@000000005aabb0fe:~# sh /home/pi/avrdude/info.sh avrdude: Version 6.3-20171130 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch System wide configuration file is "/etc/avrdude.conf" User configuration file is "/root/.avrduderc" User configuration file does not exist or is not a regular file, skipping Using Port : /dev/ttyUSB0 Using Programmer : arduino Overriding Baud Rate : 57600 AVR Part : ATmega328P Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PC2 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : Arduino Description : Arduino Hardware Version: 2 Firmware Version: 1.16 Vtarget : 0.0 V Varef : 0.0 V Oscillator : Off SCK period : 0.1 us avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e950f (probably m328p) avrdude: safemode: lfuse reads as 0 avrdude: safemode: hfuse reads as 0 avrdude: safemode: efuse reads as 0 avrdude: safemode: lfuse reads as 0 avrdude: safemode: hfuse reads as 0 avrdude: safemode: efuse reads as 0 avrdude: safemode: Fuses OK (E:00, H:00, L:00) avrdude done. Thank you. root@000000005aabb0fe:~# root@000000005aabb0fe:~# sh /home/pi/avrdude/fuses.sh avrdude: Version 6.3-20171130 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch System wide configuration file is "/etc/avrdude.conf" User configuration file is "/root/.avrduderc" User configuration file does not exist or is not a regular file, skipping Using Port : /dev/ttyUSB0 Using Programmer : arduino Overriding Baud Rate : 57600 AVR Part : ATmega328P Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PC2 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : Arduino Description : Arduino Hardware Version: 2 Firmware Version: 1.16 Vtarget : 0.0 V Varef : 0.0 V Oscillator : Off SCK period : 0.1 us avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e950f (probably m328p) avrdude: safemode: lfuse reads as 0 avrdude: safemode: hfuse reads as 0 avrdude: safemode: efuse reads as 0 avrdude: reading input file "0xff" avrdude: writing lfuse (1 bytes): Writing | | 0% 0.00s ***failed; Writing | ################################################## | 100% 0.05s avrdude: 1 bytes of lfuse written avrdude: verifying lfuse memory against 0xff: avrdude: load data lfuse data from input file 0xff: avrdude: input file 0xff contains 1 bytes avrdude: reading on-chip lfuse data: Reading | ################################################## | 100% 0.00s avrdude: verifying ... avrdude: verification error, first mismatch at byte 0x0000 0x00 != 0xff avrdude: verification error; content mismatch avrdude: safemode: lfuse reads as 0 avrdude: safemode: hfuse reads as 0 avrdude: safemode: efuse reads as 0 avrdude: safemode: lfuse changed! Was ff, and is now 0 Would you like this fuse to be changed back? [y/n] ... Die Fuses sind definitiv nicht x00 ! Der 328p arbeitet - kann mit Programmen geflashed werden, aber die Fuses lassen sich nicht beschreiben. Gruesse
Marc V. schrieb: >> Über den Bootloader lassen sich die Fuses bekanntlich nicht lesen / >> modifizieren. > > Sagt wer ? Microchip. Es gibt einfach keine AVR Befehle, um Fuses aus dem Programm heraus zu setzen.
Nun wolte ich gerade loslegen, da erkenn ich, das STK500 steuert XTAL1 an. Dieser Pin (wie auch XTAL2) werden aber von der Trägerplatine (Arduino nano mit 328p SMD) nicht über die Steckerleisten nach aussen geführt. Nun erwäge ich 3 alternative Möglichkeiten: 1. Ich verbinde mit einem Draht XTAL1 und XTAL2 auf der nano Platine und führe einen Draht von XTAL1 getrennt nach aussen zum STK500, von wo aus ich das XTAL1 Signal in den 328P einspeise. Dann bekommt XTAL2 den gleichen Impuls, da mit XTAL1 kurzgeschlossen - dürfte meiner Meinung nach nicht schädlich sein, wenn bei HVP von aussen getaktet wird. 2. Ich löte den Quarz aus (am unliebsten ...) - XTAL1 wie unter 1 nach aussen geführt. 3. Ich gehe davon aus, dass das HVP PP Prtokoll asynchron arbeitet, das heisst die Übertragungsprozedur benötigt keine externe (Gleich-)Taktung des 328p ...! Ich lasse also die XTAL1 Verbindung weg ... Dabei sei darauf hingewiesen - der 328p Prozessor arbeitet ja, also funktioniert die Taktung vom Board - nur eben geteilt durch den Faktor 8, was ich durch Korrektur der Fuses aufheben möchte. Was meint Ihr - habe ich eine Möglichkeit vergessen? Welche Möglichkeit führt am ehesten zum Erfolg? Gruesse
Ich sehe gerade RTFM ... XTAL1 wird als synchroner Taktgeber benötigt ... also versuche ich erst einmal XTAL1 und XTAL2 kurz zu schliessen -> 1. Option. Gruesse
Hendrik L. schrieb: > also versuche ich erst einmal XTAL1 und XTAL2 kurz zu schliessen Das würde ich lieber nicht tun, denn zwischen den beiden Pins liegt ein Inverter. XTAL1 ist sein Eingang, XTAL2 der Ausgang.
Bleibt die Frage, warum ISP nicht geht. Möglichkeiten: -SPIEN -RSTDISBL -DWEN Falls DWEN, gibts wohl ne Möglichkeit: https://www.mikrocontroller.net/articles/DebugWIRE Ich persönlich würde den Kram reklamieren.
Stefanus F. schrieb: > Hendrik L. schrieb: >> also versuche ich erst einmal XTAL1 und XTAL2 kurz zu schliessen > > Das würde ich lieber nicht tun, denn zwischen den beiden Pins liegt ein > Inverter. XTAL1 ist sein Eingang, XTAL2 der Ausgang. Upps - guter Hinweis. Dann werde ich im ersten Versuch einmal XTAL1 von aussen ansteuern - wie definiert - und lasse XTAL2 unbeeinflusst, in der Hoffnung, dass der Prozessor bei HVP den Quarz nicht zum Schwingen bringt ("tot" lässt), bzw. das STK500 das Quarz-signal übersteuert. Gruesse
:
Bearbeitet durch User
Warum nicht mit den billig USBasp Adaptern die Fuses setzen? Kostet 1Eu. Mach ich beim 328 auf den China "pro mini clones" dauernd ...
Der ISP ist "tot" ... USBasp ersetzt doch nur das STK500 - oder habe ich was nicht verstanden? Gruesse
So - ich habe eine erste Erfolgsmeldung - Gott sei dank auf Anhieb: HVP PP mit dem STK500 funktioniert, ich komme an den Prozessor ran - er antwortet mit Signatur und Fuse - Settings. Wobei ich einen Draht an XTAL1 des 328p SMD auf dem Board angelötet habe ... ist natürlich nicht das Gelbe vom Ei ...! Neben dem Erfolg Unschönheiten: als Signatur antwortet er mit manchmal (richtigerweise) mit 1e95of ... und überwiegend mit ff950f ... interpretiere ich 'mal mit einem Synch Problem - (Leitungslängen vom STK500 bis zum 328p Board ca. 10 - 15cm) Damit kann ich noch leben. ABER: Nachdem ich in den Fuses SPIEN gesetzt habe (checkbox Häckchen) und CKDIV8 gelöscht habe, lässt sich der Prozessor immer noch nicht über SPI ansprechen (Am STK500 samt Leitungen und Stecker liegt es nicht - Gegenprobe an anderen Prozessortypen (zB. ATtiny168) funktioniert) Bootloader funktioniert (immer noch) ...! Jetzt gehen mir so langsam die Ideen aus ...! Würde gern SPI wieder "gängig" kriegen - HVP (PP) ist einfach zu aufwendig. Jemand eine Idee? Danke & Gruesse
Hendrik L. schrieb: > Jemand eine Idee? Wie hast du die Fuses (und zwar alle) eingestellt? Zeige uns deinen Schaltplan, insbesondere interessiert mich die Stromversorgung und die Beschaltung aller Pins, die mit ISP zu tun haben.
Die Fuses sehen gut aus. Stefanus F. schrieb: > Zeige uns deinen Schaltplan, insbesondere interessiert mich die > Stromversorgung und die Beschaltung aller Pins, die mit ISP zu tun > haben.
Stefanus F. schrieb: > Die Fuses sehen gut aus. > > Stefanus F. schrieb: >> Zeige uns deinen Schaltplan, insbesondere interessiert mich die >> Stromversorgung und die Beschaltung aller Pins, die mit ISP zu tun >> haben. Das Board hat keine Verbindungen - ausser ISP zu STK500 ... Schaltplan vom Nano ist ja wohl nicht gefragt - ausserdem - es ist ein Chinaboard ...! Einzige Idee, die mir ziwschenzeitlich gekommen ist ... haben alle 6 ISP Leitungen ünerhaupt eine (korrekte) Verbindung zum Prozesso??? Werde die jetzt einmal messen. Gruesse
Was auch noch sein könnte: pullup am Reset zu klein. 3k3 oder grösser geht, mit 2k2 oder kleiner wirds eng mit dem STK500.
H.Joachim S. schrieb: > Was auch noch sein könnte: pullup am Reset zu klein. 3k3 oder grösser > geht, mit 2k2 oder kleiner wirds eng mit dem STK500. Gemessen: 4,5 kOhm Gruesse
Hendrik L. schrieb: > Das Board hat keine Verbindungen - ausser ISP zu STK500 ... > Schaltplan vom Nano ist ja wohl nicht gefragt - ausserdem - es ist ein > Chinaboard ...! Wenn es wirklich nur das Arduino Nano Board ist, ohne zusätzliche Beschaltung, kann ich dir den Schaltplan selber suchen. > haben alle 6 ISP Leitungen ünerhaupt eine (korrekte) Verbindung > zum Prozesso??? Werde die jetzt einmal messen. Das hätte ich jetzt auch empfohlen. Irgendwas wird wohl kaputt sein. Bei mir war es mal das Flachkabel zwischen Programmieradapter und Zielschaltung - obwohl es kaum gebraucht war. H.Joachim S. schrieb: > Was auch noch sein könnte: pullup am Reset zu klein. Glaube ich nicht. Die ISP Schnittstelle funktioniert während Reset auf Low liegt. Wenn sie mal wegen einem Programmfehler blockiert, empfehle ich gerne, den Reset Eingang fest mit GND zu verbinden und erst danach die Stromversorgung einzuschalten. Da der Bootloader aber funktioniert, wird das wohl auch nichts nützen.
Stefanus F. schrieb: >> Was auch noch sein könnte: pullup am Reset zu klein. > > Glaube ich nicht. Soso... Wenn der Resetwiderstand zu klein ist, schafft es der STK500-Treiber nicht, den Pin auf low zu ziehen. Und dann geht nichts via ISP. Aber hier (mit 4k7) ist das nicht das Problem.
Angehängte Dateien:
-
201904_2.jpg
230 KB
Hendrik L. schrieb: > Stefanus F. schrieb: >> Die Fuses sehen gut aus. >> >> Stefanus F. schrieb: >>> Zeige uns deinen Schaltplan, insbesondere interessiert mich die >>> Stromversorgung und die Beschaltung aller Pins, die mit ISP zu tun >>> haben. > > Das Board hat keine Verbindungen - ausser ISP zu STK500 ... > > Schaltplan vom Nano ist ja wohl nicht gefragt - ausserdem - es ist ein > Chinaboard ...! > > Einzige Idee, die mir ziwschenzeitlich gekommen ist ... haben alle 6 ISP > Leitungen ünerhaupt eine (korrekte) Verbindung zum Prozesso??? Werde die > jetzt einmal messen. > > Gruesse Alle Verbindungen zu SMD-Pins sind vorhanden ... ich glaub's nicht! Extra kurzes ISP-Kabel genommen zwischen STK500 und 328p Board - keine Veränderung - geht nicht. Ich gebe auf. Da ich sowieso über den Bootloader flashe, sind mir die Fuses einigermassen egal. Und wenn ich dennoch ran muss, dann eben über HVP - das funzt ja wenigstens. Habe extra noch einmal gecheckt - Lesen wie Schreiben ...! Und vielleicht habe ich Glück ... die meisten 328P Booards sind ISP-mässsig ja o.k. - Bootloader funzt bei denen ja auch. Nur - woran das wohl liegt, das will mir nicht in den Kopf. Wenn ich noch dahinterkomme, werde ich es hier posten. Anbei noch ein Screenshot von den 3 NANO Boards. Man sieht an den Oscillatoren (rot eingekreist), dass das ISP-funktionierende Board zumindest vom Layout unterschiedlich ist. Danke für Eure Hilfe Gruesse
H.Joachim S. schrieb: > Wenn der Resetwiderstand zu klein ist, schafft es der STK500-Treiber > nicht, den Pin auf low zu ziehen. Ach so hast du das gemeint. Hatte was anderes im Sinn, nämlich "zu schwach". Zu wenig Ohm müssten dann ja weniger als 200 Ohm sein. Wer macht das denn?
Stefanus F. schrieb: > Zu wenig Ohm müssten dann ja weniger als 200 Ohm sein. Wer macht das > denn? Nicht 200R, sondern 2k2 gehen beim STK500 schon nicht mehr. Der MKII und auch JTAG MKII sind da toleranter. Und wer das macht? Passiert in China schonmal, wenn noch ne Rolle übrig ist :-)
habe gerade das nächste Board aus der china Tüte geholt - Typ 3 im Bild - funzt tadellos. Gruesse
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.