Reset bei High Voltage Serial Programming bei TPI?

LotadaC

Sehr aktives Mitglied
22. Jan. 2009
3.547
70
48
Marwitz
Sprachen
  1. BascomAVR
  2. Assembler
Dino03 schrieb:
Das kleine Ding ist schon interessant. Aber wär für mich von der Pin-Anzahl zu klein. Ich wüßte im Moment kein Projekt wo ich ihn sinnvoll einsetzen könnte.
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)
 
Hi,

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)

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
 
Hmm...
The following sequence enables the Tiny Programming Interface (see Figure 14-3 for guidance):
•Apply 5V between VCC and GND
•Depending on the method of reset to be used:
–Either: wait tTOUT (see Table 16-4 on page 120) and then set the RESET pin low. This will reset the device and enable the TPI physical layer. The RESET then be kept low for the entire programming session
–Or: if the RSTDISBL configuration bit has been programmed, apply 12V to the RESET pin must pin. The RESET pin must be kept at 12V for the entire programming session
•Wait tRST (see Table 16-4 on page 120)
•Keep the TPIDATA pin high for 16 TPICLK cycles
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?
 
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.
 
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)
 
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.
 
Hmm...
The RESET pin must be kept at 12V for the entire programming session
Sobald ich die 12V vom Reset nehme, sollte er doch den (HV-) Tiny Programming Mode verlassen, oder?
Disabling
Provided that the NVM enable bit has been cleared, the TPI is automatically disabled if the RESET pin is released to inactive high state or, alternatively, if VHV is no longer applied to the RESET pin.
 
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.
 
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:
Datenblatt ATmega88 schrieb:
1.Power-up sequence: Apply power between VCC and GND while RESET and SCK are set to “0”. In some systems, the programmer can not guarantee that SCK is held low during power-up. In this case, RESET must be given a positive pulse of at least two CPU clock cycles duration after SCK has been set to “0”.
2.Wait for at least 20ms and enable serial programming by sending the Programming Enable serial instruction to pin MOSI.
3.The serial programming instructions will not work if the communication is out of synchronization. When in sync. the second byte (0x53), will echo back when issuing the third byte of the Programming Enable instruction. Whether the echo is correct or not, all four bytes of the instruction must be transmitted. If the 0x53 did not echo back, give RESET a positive pulse and issue a new Programming Enable command.
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...
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ß...)
 
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?
 
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:
When the pull-up is detected, the debugger initiates the enable sequence by driving the line low
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.
After tri-stating, the UPDI will remain in reset until the RESET pin is driven low by the debugger.
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.
 
Der folgende Punkt ist mir unklar:
When the pull-up is detected, the debugger initiates the enable sequence by driving the line low
Das heißt, daß der Tiny nach dem PowerUp immer(!) quasi sofort in den Programming Mode geht??
Im Prinzip ja, der Satz geht aber weiter:
for a minimum of 200ns and a maximum of 1us
Das verstehe ich so, daß, wenn der Puls nicht kommt, der Controller einen ganz normalen POR macht.
Damit sollte sich doch eigentlich folgendes realisieren lassen:
...
Sehe ich auch so.
Wie schalte ich prellfrei die 12V auf den Tiny (und gebe sie wieder frei)?
Pullup an 12V, über Transistor/FET schaltbar.
Wie verbinde (und trenne) ich die beiden UPDI-Signale (Tiny <--> Programmer) prellfrei?
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... ;)
 
Zuletzt bearbeitet:
Im Prinzip ja, der Satz geht aber weiter:
Nochmal als Ganzes:
When the pull-up is detected[1], the debugger initiates the enable sequence by driving the line low for a minimum of 200ns and a maximum of 1 us [2] to ensure that the line is released from the debugger before the UPDI enable sequence is done.[3]
The negative edge is detected by the UPDI, which requests the UPDI clock. The UPDI will continue to drive the line low until the clock is stable and ready for the UPDI to use. The duration of this will vary, depending on the status of the oscillator when the UPDI is enabled. A start-up time between 10us and 200us can be expected. After this duration, the data line will be released by the UPDI, and pulled-high.[4]
When the Debugger detects that the line is high, the initial SYNCH character (0x55) must be sent to properly enable the UPDI for communication[5]. If the start bit of the SYNCH character is not sent within 13.5ms, the UPDI will disable itself, and the enable sequence must be repeated. This time is based on counted cycles on the 4MHz UPDI clock, which is default when enabling the UPDI. The disable is performed to avoid the UPDI being enabled unintentionally[6].
[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.
[Reset-Puls durch den Programmer 200ns..1µs] Das verstehe ich so, daß, wenn der Puls nicht kommt
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
Pullup an 12V, über Transistor/FET schaltbar.
Ja, an sowas in der Art hatte ich auch etwa gedacht, ok.
Aber...
Wenn der Programmerausgang 12V toleriert - kein Problem,
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.
sonst Zenerdiode nach Masse, Reihenwiderstand an UPDI-Pin??
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
das der ICE die neuen Xtinies programmieren können soll...
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.
PS: Das verlinkte Datenblatt hat nur 500 Seiten... ;)
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*
 
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.
 
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.
Dazu finde ich nichts. In den Webdocs findet sich hingegen sogar:
Communication between the Atmel-ICE and the target device is done through a bank of level converters that shift signals between the target's operating voltage and the internal voltage level on the Atmel-ICE. Also in the signal path are zener overvoltage protection diodes, series termination resistors, inductive filters and ESD protection diodes. All signal channels can be operated in the range 1.62V to 5.5V, although the Atmel-ICE hardware can not drive out a higher voltage than 5.0V.
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:
Zum Selbstbau: vielleicht mit ‘nem Analogmultiplexer á la 4053 zwischen Programmer und 12V umschalten.
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...
 
Zuletzt bearbeitet:
Dazu finde ich nichts.
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
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.
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.
Mit einem Kanal 12V oder nix auf die Target-Seite schalten, mit einem zweiten Kanal die Programmerseite auf Gnd oder die Target-Seite schalten.
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.
 
Aber würde der Hersteller der Controller und des Programmers seine professionellen Kunden so im Regen stehen lassen?
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...
Der 12V-Puls soll den Controller in einen programmierbaren Zustand versetzten, wäre quasi einem Reset vergleichbar
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)
Ich dachte eigentlich an einfaches Umschalten,
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...
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.
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...)
 
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.
Vdd muß also dann auch 12V sein. Sehe ich das richtig, daß...
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...
 
Es heißt übrigens High-Voltage ResetBildschirmfoto_2018-02-07_21-01-16.png
 
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

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)