Reset bei High Voltage Serial Programming bei TPI?

Dieses Thema im Forum "Allgemeines" wurde erstellt von LotadaC, 21. Februar 2015.

  1. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.913
    Zustimmungen:
    43
    Punkte für Erfolge:
    48
    Sprachen:
    BascomAVR, Assembler
    Normalerweise wird der Reset (zum Programmieren) eingeleitet, indem der Reset-Pin auf low gezwungen wird. Meiner Meinung nach besitzt ein Programmer wie der AVRISP mkII dazu einen Open Collector Ausgang, der die entsprechende Leitung auf Gnd verbinden kann. Wurde der Reset jedoch zum I/O gefused, geht das natürlich nicht mehr.
    Allerdings kann man den Pin auch dann noch auf 12V legen, um den Reset auszulösen.
    Gesucht ist jetzt also eine möglichst kleine Schaltung, die aus dem active Ground am Eingang 12V am Ausgang macht, und sonst tristate ist.

    Die 12V könnte man aus Vtgmit einem kleinen (SOT23) Schaltregler erzeugen lassen (mit 'ner 10µH Induktivität in 1206), aber wie das mit dem invertieren und tristate realisieren?
    Irgendwie komme ich da mit den MOSFETs nicht klar...

    Diiinoooo....

    (Ich will weder auf dem Eingang (also wo der AVRISP mkII Reset-Ausgang dranhängt) 12V haben, noch auf dem Ausgang (wo dann der Target Reset-Eingang angeschlossen wird) 5V)
     
  2. dino03

    dino03 Moderator

    Registriert seit:
    27. Oktober 2008
    Beiträge:
    6.674
    Zustimmungen:
    12
    Punkte für Erfolge:
    38
    Sprachen:
    BascomAVR, Assembler
    Hi,

    hmmm ... willst du ihn einfach mit 12V statt mit GND in die HV-Programmierung schicken und dann den selben Prog-Algorithmus verwenden? Sind die Bit-Ketten die du in den Chip übertragen mußt überhaupt identisch? Ich fürchte nicht.

    Für die Invertierung müßtest du den Spannungswandler lediglich dazu bringen das er bei Vcc am Reset geblockt wird (Transistor gesperrt, oder was weiß ich). Ohne Vcc läuft er dann. Wäre also ein PullUp nötig.

    Gruß
    Dino
     
  3. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.913
    Zustimmungen:
    43
    Punkte für Erfolge:
    48
    Sprachen:
    BascomAVR, Assembler
    Hmm...
    Den Regler selbst über seinen Enable-Eingang zu steuern hatte ich auch schon überlegt, aber als Aufwärtswandler liegt da ja wenn er inaktiv ist trotzdem die Eingangsspannung auf dem Ausgang, nicht tristate.
    Und wenn ich den einfach immer wandeln lasse, und den Ausgang mit einem Transistor in Basisschaltung (FET in Gateschaltung) unterbrechen lasse, hab ich durch den Pull-Widerstand immer die 12V am Reset-Signal des AVRISP. Das will ich nicht riskieren. Da werden wohl mehrere Stufen nötig sein, oder?
     
  4. Hubert.G

    Hubert.G Mitglied

    Registriert seit:
    21. Juli 2013
    Beiträge:
    35
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Da war doch was bei den ersten Arduino UNO das über die DTR-Leitung und dem in Serie liegenden Kondensator ein HV-Reset ausgelöst wurde.
    Es war ein manueller Reset notwendig um den Kontroller zum Laufen zu bringen.
    Behoben wurde der Fehler durch eine Diode parallel zum Reset-PullUp.
    Das könnte man doch nutzen für ein HV-Reset. Hab es aber nicht ausprobiert, ist nur so ein Gedanke von mir.
     
  5. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.913
    Zustimmungen:
    43
    Punkte für Erfolge:
    48
    Sprachen:
    BascomAVR, Assembler
    Sagt mir irgendwie nichts, haste mal'ne Quelle?

    Die anderen I/Os haben ja alle Schutzdioden gegen Vcc und Gnd, ein HV-fähiger Reset-Pin logischerweise nicht. Legt man da nun 'ne externe Diode gegen Vcc, werden (unbeabsichtigte) 12V-Spannungen abgeleitet, ein HV-Reset kann nicht merh ausgelöst werden.

    Ich will aber die 12V auf den Reset-Pin legen solange der Programmer die Leitung auf Gnd zieht (also die gesamte Programmierphase lang). Gibt der Programmer die Leitung frei, soll auch meine Schaltung den Pin freigeben. Außerdem möchte ich keine Spannung höher als 5V auf den Reset-Ausgang des Programmers legen (durch irgendwelche Pullups - normalerweise zieht ja der AVR-Interne Pullup am Reset die Leitung auf Vtg).

    Hab mal 'ne Weile rumgegrübelt (wie gesagt: MOSFETs sind (noch) nicht mein Ding):

    HV_TPI.png
    Kann das so passen, oder sind da irgendwelche Böcke drin, Dino? Irgendeinen besseren Vorschlag?
    P.S.: Werte hab ich jetzt noch keine drangemalt/ausgerechnet, wäre ja so schön klein mit 2 x SOT23 und etwas 1206er Hühnerfutter...
    (Frage wäre so auch, ob der Wandler schnell (und stabil) genug auf 12V hochkommt)
     
  6. Hubert.G

    Hubert.G Mitglied

    Registriert seit:
    21. Juli 2013
    Beiträge:
    35
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ich hab schon gesucht aber nichts mehr gefunden. Das ist doch schon einige Zeit her.
    Genau diese Diode hat in den ersten Versionen des Arduino gefehlt.
    Es gibt damit aber nur einen Impuls der das HV auslöst. Sollte aber genügen.
    Zum Starten des Programms ist dann ein Reset notwendig.
     
  7. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.913
    Zustimmungen:
    43
    Punkte für Erfolge:
    48
    Sprachen:
    BascomAVR, Assembler
    Hmm...
    Sobald ich die 12V vom Reset nehme, sollte er doch den (HV-) Tiny Programming Mode verlassen, oder?
     
  8. Hubert.G

    Hubert.G Mitglied

    Registriert seit:
    21. Juli 2013
    Beiträge:
    35
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Wenn man das liest sollten die 12V dauernd anliegen.
    Braucht man nach dem HV-Programming einen Reset das der Programmablauf startet?
    Schade das ich den Beitrag nicht mehr finde.
     
  9. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.913
    Zustimmungen:
    43
    Punkte für Erfolge:
    48
    Sprachen:
    BascomAVR, Assembler
    Hmm... jetzt haste mich nochmal ins Grübeln gebracht...
    So'n "Reset" beinhaltet ja 2 Sachen:
    Erstens das "Anhalten" des Controllers, wobei alle Beinchen Tristate geschaltet werden (beim normalen Low-Level-Reset ist das der Fall während der Pin auf Gnd liegt)
    Zweitens das Starten des Programmes nach Abwarten eines Timeouts und reinitialisieren aller I/O-Register auf initial values und setzen des Programm-Counters auf 0x00, nachdem der Pin wieder Hi gegangen ist (beim low-level-Reset).
    Jetzt kurz was zum seriellen ISP über SPI:
    Schritt 1 bedeutet, daß man jedesmal beim Start des Programmierens den Strom vom Target nehmen müßte (da Reset und SCK vor anlegen der Spannung auf Gnd liegen sollen). Allerdings steht in Schritt 3, daß man sonst einfach den Reset nochmal kurz freigeben, und nochmal anziehen soll.
    Hält man den Controller dann im Reset fest, wird mit 0xAC 0x53 0x00 0x00 der SPI-Programming-Mode aktiviert ("entering programming mode").
    Wird der Reset irgendwann wieder freigegeben (und geht hi), sind wir wieder bei der Erklärung oben - timeout, I/Os reinitialisieren, PC auf null und los gehts...[HR][/HR]Hier gehts jetzt aber um das TPI
    Und da findet sich nur:
    • Versorgungsspannung anlegen (5V)
    • TPI-Programming-Mode einleiten (Reset halten)
      • Entweder durch Reset->low Pegel
      • Oder durch Reset->12V (wobei hier noch die Frage ist, ob das auch ohne gesetztem RSTDISBL so ist)
    • über TPIDATA 16 einsen einclocken
      ...
    • TPI-Programming-Mode verlassen (weniger als 11,5V am Reset-Bein, bei inaktivem RSTDISBL-Bit im Configuration-Byte (sind ja hier keine Fuses) muß dann natürlich ein Hi-Pegel erfolgen)

    Wie gesagt hast Du mich jetzt ins Grübeln gebracht: löst das freigeben des Reset auch im HV einen Neustart (inklusive reinit usw) aus? Sollte aber eigentlich so sein, sonst bliebe ja nur noch ein Power On Reset, da der Pin ja wegen RSTDISBL eh keinen low-Lever-Reset generieren könnte...

    Hmm... vielleicht sollte ich das einfach mal ausprobieren (Led an ein Bein und blinken lassen, ohne Programmer dran den Reset auf 12V legen (Blinken aus?), Reset wieder freigeben (Blinken wieder an?), mit dem AVRISP RSTDISBL setzen, nochmal die beiden ersten Schritte testen, und dann nochmal den Programmer anschließen, wobei die Reset-Leitung nicht verbunden wird sondern der Pin am Controller fest auf 12V liegt, und versuchen RSTDISBL wieder rauszunehmen...

    Im ungünstigsten Fall hab ich mich dann aus dem Tiny10 ausgesperrt...

    (Achso, gefährlich wirds u.U., wenn das Programm den Reset-Pin auf Ausgang (also Vcc oder Gnd) schaltet, und extern 12V drauf landen. Das wird aber im normalen Programmierversuch auch so sein, wen der Programmer den eventuell Ausgang Hi geschalteten Pin auf Gnd legt nur eben mit weniger Spannung. Man sollte den Reset als wenn überhaupt, möglichst nur als Input, nicht als Output verwenden wenn reprogrammiert werden können soll...
    (abgesehen davon, daß die Schaltung dann dort auch auf 12V ausgelegt sein muß...)
     
  10. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.913
    Zustimmungen:
    43
    Punkte für Erfolge:
    48
    Sprachen:
    BascomAVR, Assembler
    So...
    • 'N Fünfzeiler geschrieben, der im Timer-IRQ 'ne LED an B2 toggelt
    • Das ganze in'n Tiny10 geflasht --> LED blinkt
    • Reset abgezogen --> LED blinkt weiter
    • Reset auf Gnd -->LED aus
    • Reset offen --> LED blinkt wieder
    • Reset auf 12V --> LED aus
    • Reset offen --> LED blinkt wieder
    • Reset an Progger --> LED blinkt weiter
    • Fuses gelesen --> LED blinkt
    • RSTDSBL gesetzt (und geschrieben) --> Led blinkt weiter, Fehlermeldung (Fuses verify?)
    • Fuses auslesen lassen schlägt fehl
    • Reset getrennt --> LED blinkt
    • Reset auf Gnd --> LED blinkt
    • Reset auf Vcc --> LED blinkt
    • Reset auf 12V --> LED aus
    • Fuses auslesen --> geht
    • RSTDISBL gelöscht (und geschrieben) --> geht, LED immer noch aus (12V auf Reset, klar)
    • Reset offen --> LED blinkt wieder
    • Reset an Progger --> LED blinkt
    • Fuses Lesen --> geht
    • Chip erase --> LED aus
    Scheint also so zu passen, haste jetzt mal'ne Meinung zur Schaltung aus Beitrag #5, Dino?
     
  11. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.913
    Zustimmungen:
    43
    Punkte für Erfolge:
    48
    Sprachen:
    BascomAVR, Assembler
    Vorweg: habe mich mit dieser Schaltung nicht weiter baschäftigt - grundsätzlich kann man einen TPI-Tiny also durch anlegen von 12V an den Resetpin (egal wie der "gefused" ist (*)) in den Reset zwingen, und während dieses HV-Resets mit ganz normalem Low-Voltage-TPI programmieren (abgesehen vom nicht angeschlossenem Reset seitens des Programmers).

    (*):wenn das Programm den zum Ausgang macht, sollten die 12V zusammen mit der Spannungsversorgung während des PowerUps anliegen, also bevor der POR + SUT abgelaufen sind.

    Jetzt möchte ich das Thema (nochmal) auf die neuen UPDI-Tinies ausweiten. Hier gibt es generell das Problem, daß nur eine Leitung verwendet wird. Also bidirektional. Ich fasse mal zusammen, wie ich das bisher verstanden habe:
    Der Pin kann als UPDI oder /Reset oder konventioneller I/O gefused werden.
    Bei "UPDI" wird während des PowerUps automatisch der Pullup aktiviert -> der Pegel geht auf Vcc, was der Programmer erkennt.
    Der folgende Punkt ist mir unklar:
    Das heißt, daß der Tiny nach dem PowerUp immer(!) quasi sofort in den Programming Mode geht??
    Bei SPI und TPI löse ich(!) den Vorgang doch normalerweise im Studio durch den Programmer aus - wenn ich zB die Fuses lesen lasse, wird der Reset angezogen (wenn möglich sonst Fehlermeldung), der programming mode aktiviert usw...
    Ist das beim UPDI anders?

    Jedenfalls versucht der Programmer anschließend, den UPDI-Pin runterzuziehen (kurz - der Tiny schaltet quasi als ACK dann selbst auf Gnd, was der Programmer detektiert. Wenn der Tiny mit seinem UPDI-Init fertig ist, gibt er den Pin frei).
    Wenn die Leitung wieder High ist, begint der Programmer mit Clock-Synchronisationsimpulsen und dem restlichen Protokoll.

    Wenn der UPDI-Pin aber anders gefused ist, kann der Tiny durch einen 12V-Puls am UPDI-Pin in den UPDI-Reset gezwungen werden.
    Empfohlen wird das nach(!) einem POR, der Controller muß also erstmal laufen. Eine steigende (auf 12V) Flanke erzwingt den UPDI-Reset, bis der Pin (durch den Programmer) auf Gnd gezogen wird.
    Der Rest entspricht dem Low-Voltage-UPDI.

    Damit sollte sich doch eigentlich folgendes realisieren lassen:
    Programmer und Tiny sind nur mit Gnd verbunden.
    PowerUp des Tiny.
    12V auf den UPDI-Pin des Tiny
    Pin freigeben (sollte anschließend durch den PullUp des Tiny auf Vcc gehen)
    UPDI von Tiny und Programmer verbinden.
    (Programmiervorgang im ATMEL-Studio etc. auslösen.)

    Die Fragen sind nun:
    • Wie schalte ich prellfrei die 12V auf den Tiny (und gebe sie wieder frei)?
    • Wie verbinde (und trenne) ich die beiden UPDI-Signale (Tiny <--> Programmer) prellfrei?
    Informationen zum UPDI finden sich in den Datenblättern der Controller, zB beim ATtiny816 auf den Seiten 508 und 509.
     
  12. Mikro23

    Mikro23 Mitglied

    Registriert seit:
    2. Januar 2017
    Beiträge:
    228
    Zustimmungen:
    18
    Punkte für Erfolge:
    18
    Sprachen:
    C, Assembler
    Im Prinzip ja, der Satz geht aber weiter:
    Das verstehe ich so, daß, wenn der Puls nicht kommt, der Controller einen ganz normalen POR macht.
    Sehe ich auch so.
    Pullup an 12V, über Transistor/FET schaltbar.
    Wenn der Programmerausgang 12V toleriert - kein Problem,
    sonst Zenerdiode nach Masse, Reihenwiderstand an UPDI-Pin??

    Vor kurzem habe ich irgendwo gelesen, das der ICE die neuen Xtinies programmieren können soll...

    PS: Das verlinkte Datenblatt hat nur 500 Seiten... ;)
     
    #12 Mikro23, 6. Februar 2018
    Zuletzt bearbeitet: 6. Februar 2018
  13. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.913
    Zustimmungen:
    43
    Punkte für Erfolge:
    48
    Sprachen:
    BascomAVR, Assembler
    Nochmal als Ganzes:
    [1] steigende Flanke durch den Tiny
    [2] der Programmer zieht auf Gnd - warum jetzt? Beim TPI, SPI kann ich den Programmer steckenlassen während das Programm läuft - und ich entscheide im Studio, wann 'n Programming-Zugriff erfolgen soll. UPDI-Reset wird gehalten.
    [3] der Tiny reagiert auf die fallende Flanke, indem er seinerseits UPDI auf Gnd zieht, und startet/initialisiert sein UPDI. Der Programmer muß rechtzeitig loslassen, um dies zu erkennen. Deswegen max. 1µs.
    [4] wenn der Tiny mit dem StartUp fertig ist, signalisiert er das, indem er UPDI wieder freigibt (Vcc durch Pullup).
    [5] der Programmer detektiert diese steigende Flanke, und beginnt mit der Synchronisation, was UPDI-Programming letztendlich enabled.
    [6] ist 13,5ms nach... was eigentlich? [2]? [1]? Ist jedenfalls diese Synchro dann noch nicht erkennbar, schaltet der Tiny sein UPDI ab. Ob er dann mit einem normalen POR loslegt, ist mir nicht ersichtlich.
    Was geschieht, wenn man den Pin irgendwann im laufenden Betrieb runterzieht? Wenn UPDI wirklich nur 13,5ms nach einem PowerUp möglich sein sollte, bräuchte man keine extra Reset-Fuse-Möglichkeit - dann könnte nach dem UPDI-Timeout ja grundsätzlich ein konventioneller Reset folgen (ok, die SUT wäre länger).
    Ich wär mir nichtmal sicher, ob der Programmer wirklich die steigende Flanke beim PowerUp braucht, oder ob er einfach einen High-Pegel erwartet/abwartet/vorraussetzt.
    Der Programmer erzeugt den Impuls. Mindestens 200µs lang, damit er vom Tiny erkannt werden kann und dieser den low-Pegel übernehmen/weiter halten kann, maximal 1µs lang, damit er erkennt, daß der Tiny übernommen hat. Weil der Tiny irgendwann (SUT usw) auch losläßt.
    So würde ich es verstehen.

    Soweit der normale Low-Voltage-UPDI.

    Wenn der Tiny auf GPIO oder Reset gefused ist, erzwingt ein 12V-Pegel am Pin den UPDI-Mode (bzw schaltet den zeitweise um).
    Es wird empfohlen, den Impuls nach einem PowerUp aufzulegen. Wenn der Pin I/O ist, wird der Output nach einem (PowerUp)Reset nämlich 8,8ms blockiert, um Spannungskonflikte auszuschließen (beim Reset ist er eh nur über'n Pullup hochgezogen).
    Ob danach dann trotzdem ein 12V-Reset möglich ist, geht daraus nicht hervor. Dann sollte der Pin natürlich nicht als Output verwendet werden.
    Wenn der 12V Puls einmal erfolgt ist (steigende Flanke auf 12V), ist die Fuse bis zum nächsten PowerUp overriden, der Pin ist UPDI.
    Außerdem befindet sich der Tiny (nachdem UPDI wieder auf Vcc gesunken ist) solange im Reset, bis UPDI auf Gnd gezogen wird.

    12V-Puls
    Ja, an sowas in der Art hatte ich auch etwa gedacht, ok.
    Aber...
    Bei einem HV-UPDI-fähigen ist das sicher so, aber dann ist das hier eh alles egal.
    Ein Programmer der von sich aus nicht HV-fähig ist, wird möglicherweise nicht tolerant sein. Ich würds nicht riskieren wollen.
    Dann hab ich, wenn ich die 12V aufschalte 'n Spannungsteiler aus dem Pullup und (Reihenwiderstand und Zener). Der Pullup muß also klein genug gegen den Reihenwiderstand sein, um 12V auf den Tiny bringen zu können. Der Reihenwiderstand muß (mit dem PullUp) groß genug sein, um den Strom durch die Zener zu begrenzen.
    Auf der anderen Seite sollen Zener und Pullup aber den UPDI-Verkehr nicht/möglichst wenig verbiegen.
    Wenn die beiden UPDI-Seiten aber währenddessen verbunden sind, würde der Programmer aber den Pegelanstieg Gnd->Vcc erkennen, und (?) seinerseits bereits UPDI runterziehen.
    Man müßte also die Leitung programmerseitig des Reihenwiderstandes auf Gnd ziehen, bis (tinyseitig) der 12V erfolgt ist, und dort das Signal wieder auf Vcc runter ist.
    Also:
    Vtg aus
    UPDI programmerseitig auf Gnd zwingen
    Vtg an
    irgendwann (max nach 8,8ms) tinyseitig für 500µs 12V auf UPDI
    wenn dort wieder Vtg, UPDI programmerseitig freischalten
    Ja, aber nur Low Voltage. Genau darum geht's ja.
    Der AVRisp mkII kann ja auch kein HV-TPI, aber mit wenn man einen TPI-Tiny mit externen 12V in den Reset zwingt, kann der AVRisp ihn ganz normal (low voltage) programmieren. Siehe #10.
    Wenn man auf ähnlichem Wege einen UPDI-Tiny mittels externem 12V-Puls in den UPDI-Mode schubsen kann, sollte man auch hier mit dem ICE programmieren können, wenn der Pin als Reset oder I/O gefused ist.
    Ups.
    Haben sie da umgeräumt? Als ich es mir damals gezogen hatte, es noch 605 Seiten, galt für ATtiny 417/814/816/817 und hieß ATMEL-42721C. Ok, Preliminary. 12/2016. Sorry.
    Das war ja auch noch nicht von Micromel... äh... Atmochip... oder wie auch immer.
    *Link nachreich*
     
  14. Mikro23

    Mikro23 Mitglied

    Registriert seit:
    2. Januar 2017
    Beiträge:
    228
    Zustimmungen:
    18
    Punkte für Erfolge:
    18
    Sprachen:
    C, Assembler
    Beim Xmega werden für den PDI zwei Pins benutzt, Reset für Clock und der PDI-Pin für bidirektionalen Datenaustausch. Das sieht fast aus wie UPDI, nur auf zwei Leitungen aufgeteilt.

    Also würde ich davon ausgehen, daß UPDI im Normalfall so ähnlich funktioniert wie PDI, also Programmierstecker bleibt stecken (bei Programmentwicklung) und man kann jederzeit in den Programmier- oder Debugmodus schalten, wenn man will.

    Zumindest, solange man den UPDI-Pin nicht umprogrammiert.
    Ich meine irgendwo gelesen zu haben, daß der ICE neuerdings 12V kann, weiß aber nicht mehr wo.
    Die älteren können es jedenfalls nicht und ich weiß auch nicht ob man die aufrüsten könnte.

    Die Beschreibungen in den Datenblättern finde ich auch etwas zu ungenau. Hilft wohl nur ausprobieren.

    Zum Selbstbau: vielleicht mit ‘nem Analogmultiplexer á la 4053 zwischen Programmer und 12V umschalten.
     
  15. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.913
    Zustimmungen:
    43
    Punkte für Erfolge:
    48
    Sprachen:
    BascomAVR, Assembler
    Dazu finde ich nichts. In den Webdocs findet sich hingegen sogar:
    Also quasi dasselbe wie beim AVRisp mkII.
    Gegenüber SPI-HVSP oder HVPP hast Du beim HV-TPI und HV-UPDI aber kein anderes (gegenüber des jeweiligen LV-...)... ähm ... Programmierprotokoll.
    Beim TPI wird programmiert, während der Reset angezogen ist. Beim Target ist es egal, ob dieser Zustand durch einen Gnd- oder 12V-Pegel erreicht wird. Der AVRisp mkII kann Reset nur von 5V auf Gnd ziehen (ggf auch andersrum für einige Relikte mit umgekehrter Reset-Polarität). Extern kann man aber den 12V-Reset am Target auslösen, und den AVRisp via TPI proggen lassen.
    Beim UPDI ist mir das nicht ganz klar. Wenn der Pin nicht mehr auf UPDI gefused ist, ist die interne UPDI-Hardware nicht mehr angebunden, klar.
    Wenn er auf UPDI gefused ist, kann der Programmer mit der Hardware kommunizieren. Ob nur nach dem PowerUp, oder jederzeit ist nicht klar. Grundsätzlich muß ein UPDI-Zugriff ja nicht zwingend den Controller resetten etc.
    Ein 12V-Puls am UPDI-Pin erzwingt den Zustand, als wenn der Pin auf UPDI gefused wäre. Bis zum nächsten PowerUp. Meiner Meinung nach wird dabei kein Reset des Controllers durchgeführt - lediglich die UPDI-Hardware wird resettet.
    Nachtrag:
    Mit einem Kanal 12V oder nix auf die Target-Seite schalten, mit einem zweiten Kanal die Programmerseite auf Gnd oder die Target-Seite schalten.
    Vdd bräuchte man dann wegen den zu bewältigenden 12V auch 12V, oder? Dann müssen die Schaltsignale auch hinreichend hoch sein(1)...
    Hmm... eine kleine Platine mit 'nem Tiny10/25 oder so, die beiden Schalter bedient, die Spannung am Target schätzen kann, ggf ein Taster zum auslösen...
    Versorgt über externe 12V (+5V-Regler) - aus Vtg mittels 12-StepUp wird wohl wegen (1) nicht reichen (ohne weitere (FE)Ts)...
    Bei Bedarf dann das ganze un die UPDI-Leitung klemmen...
     
    #15 LotadaC, 7. Februar 2018
    Zuletzt bearbeitet: 7. Februar 2018
  16. Mikro23

    Mikro23 Mitglied

    Registriert seit:
    2. Januar 2017
    Beiträge:
    228
    Zustimmungen:
    18
    Punkte für Erfolge:
    18
    Sprachen:
    C, Assembler
    Vielleicht habe ich es mißverstanden, finde die Stelle aber auch nicht wieder.
    Aber würde der Hersteller der Controller und des Programmers seine professionellen Kunden so im Regen stehen lassen?

    Nun ja, bei den Preisen und bei kleinen Baugruppen, die in riesigen Stückzahlen hergestellt werden, ist es wohl wirtschaftlicher garnicht erst nach Fehlern zu suchen, sonder einfach zu entsorgen. Da braucht man dann auch keinen HV-Programmer mehr, um die Chips noch mal wiederzubeleben… :D
    Debuggen mit Atmel-Studio über PDI fängt immer mit neuflashen an, d.h. nach dem Programmieren startet der Controller wie beim Reset und bleibt dann nach der Initialisierung oder beim ersten gesetzten Breakpoint stehen.

    Der 12V-Puls soll den Controller in einen programmierbaren Zustand versetzten, wäre quasi einem Reset vergleichbar, anderes hätte doch keinen Sinn.
    Ich dachte eigentlich an einfaches Umschalten, weiß aber nicht, ob der 4053 das bei 12V kann. Es gibt aber noch viele andere CMOS-(Um)schalter. Vielleicht müßte man zwei einzelne nehmen. Einen mit 12V und einen mit Vtarget betrieben.
     
  17. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.913
    Zustimmungen:
    43
    Punkte für Erfolge:
    48
    Sprachen:
    BascomAVR, Assembler
    Als professioneller Kunde hast Du 'n STK600 nebst passender Routingcard und passender Topcard, oder wie die Dinger da heißen. Mindestens.
    Bei SPI & co war das doch auch nicht anders - ging mit AVRisp (classic) und AVRisp mkII nicht. Brauchtest Du 'n STK500 für (ob der Dragon das kann, hat Thomas hier schon drölfzich mal beantwortet - ich wills mir schlichtweg nicht merken). Oder irgendwas selbsgebasteltes, was dasselbe Protokoll wie'n STK500 (STK200 ?) fährt.
    Ich hab zwei selbstgebaute AVRisp Clone (die wegen USB-1 mit aktuellen PCs eh nicht mehr laufen, einer scheint zu 'ner Dauerleihgabe geworden zu sein), ein STK500 und einen AVRisp-mkII. wegen den XTinies würde ich mir noch'n ICE zulegen (und um Dirk zu unterstützen) - 'n STK600 ist mir zu heftig...
    Meiner Meinung nach erfolgt durch den Puls nur ein Override der UPDI-Fuse, und macht das UPDI bereit. der Reset wird erst durch eine danach erfolgende Flanke (Vtg->Gnd) ausgelöst. Meine Meinung. Sollte sich ja, wenn man die Hardware mal hat mit'nem Fünfzeiler rausfinden lassen. (Würde auch'n XTiny zum testen einer Selbsbaulösung riskieren)
    Dann würde UPDI programmerseitig in der Luft hängen, während des Pulses. Könnte man natürlich mit'n hinreichend schwachen Pulldown vermeiden, aber...
    Der Schalter, der beide Seiten verbinden kann muß aber Target-seitig 12V-tolerant sein. Zumindest im Datenblatt des CD4053B (von Ti) finden sich an den Beinen Schutzdioden. Vdd muß also dann auch 12V sein. Sehe ich das richtig, daß ein sicher erkanntes low an den Steuereingängen bei <3..4V liegt, ein sicher erkannte high bei >7..11V? Hab das bei den XTinies grad nicht im Kopf, aber Vtg bis 2,7V oder so sollte schon drin sein. Einige AVR laufen ja auch bei 1,8V.
    Wenn da eh FETs zwischen müßten, kann man die 12V auch gleich durch den FET auf das Target legen - zum trennen wäre irgendso'n Schalter natürlich wünschenswert.
    (Eigentlich wollte ich die Schaltung (bzw 'ne ähnliche) aus dem Anfang dieses Threads mit meinem AVRisp in ein gemeinsames Gehäuse verfrachten. Tendenziell werd ich jetzt wohl eher 'ne Schaltung suchen, die UPDI und TPI kann - der AVRisp bekommt ein neues Gehäuse, die Schaltung auch, beide können zusammengesteckt werden. Statt des AVRisp kann man aber auch den Hosenträger vom ICE anstöpseln...)
     
  18. Mikro23

    Mikro23 Mitglied

    Registriert seit:
    2. Januar 2017
    Beiträge:
    228
    Zustimmungen:
    18
    Punkte für Erfolge:
    18
    Sprachen:
    C, Assembler
    Es gibt sicher so‘ne und solche Profis. Für die, die ich kenne sind die STKs eher Spielkram, die benutzen ‘nen einfachen AVRisp ohne Debugger.
    Ich habe einen Dragon und einen ICE. Die HV-Programmierung habe ich bisher noch garnicht gebraucht und den Debugger nur selten.
    Ja. Wenn z.B. 12V (über Pullup) an ax (Pin 12) liegt, der Programmeraus&eingang an ay (Pin 13) und der UPDI-Pin des Controllers am gemeinsamen a-Ein&ausgang (Pin 14), dann kann man mit 12V am Steuereingang A (Pin 11) zwischen 12V und Programmer umschalten. Vom und zum Programmer geht maximal Vtarget, die 12V gehen nur an den Controller und nur dann, wenn umgeschaltet ist.
    So verstehe ich das, kenne den Chip aber nicht so gut um zu behaupten, daß es funktionieren muß.

    Man kann das ganze sicher auch mit FETs oder sonstwie anders machen, es gibt meistens viele Möglichkeiten...
     
  19. Mikro23

    Mikro23 Mitglied

    Registriert seit:
    2. Januar 2017
    Beiträge:
    228
    Zustimmungen:
    18
    Punkte für Erfolge:
    18
    Sprachen:
    C, Assembler
    Es heißt übrigens High-Voltage Reset Bildschirmfoto_2018-02-07_21-01-16.png
     
  20. LotadaC

    LotadaC Sehr aktives Mitglied

    Registriert seit:
    22. Januar 2009
    Beiträge:
    2.913
    Zustimmungen:
    43
    Punkte für Erfolge:
    48
    Sprachen:
    BascomAVR, Assembler
    richtig, aber ob sich das nur auf das UPDI, oder auch auf den ganzen Controller auswirkt, ist damit nicht gesagt. Letztendlich auch egal. Hinterher verhält er sich, als wenn er auf UPDI gefused wäre.
     
  • Über uns

    Unsere immer weiter wachsende Community beschäftigt sich mit Themenbereichen rund um Mikrocontroller- und Kleinstrechnersysteme. Neben den Themen Design von Schaltungen, Layout und Software, beschäftigen wir uns auch mit der herkömmlichen Elektrotechnik.

    Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  • Coffee Time

    Unser makerconnect-Team arbeitet hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und unser eigener makerconnekt-Server regelmäßig gewartet wird. Wir nehmen das Thema Datensicherung und Datenschutz sehr ernst und sind hier sehr aktiv, auch sorgen wir uns darum, dass alles Drumherum stimmt!

    Dir gefällt das Forum und die Arbeit unseres Teams und du möchtest es unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft, unser Team freut sich auch über eine Spende für die Kaffeekasse :-)
    Vielen Dank!
    Dein makerconnect-Team

    Spende uns! (Paypal)
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren und die Seite optimal für dich anzupassen. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden