"Universalprogrammer" für Linux

[Joerg W. (joergwolfram)]

Nachdem es entsprechende Nachfrage gab, habe ich mein 
Universalprogrammer-Projekt etwas aufgeräumt und dokumentiert.

http://www.jcwolfram.de/projekte/uprog2/main.php

Hauptgrund für die Entwicklung war damals, dass es für die 
Programmierung von HCS12XE-Controllern nichts Brauchbares unter Linux 
gab, nach und nach sind dann weitere Controllerfamilien dazugekommen.

Als Controller kommte ein ATMega644 zum Einsatz, derzeit sind noch etwa 
20K Flash frei. Von der Hardware her ist derzeit nur die USB-Variante 
ausführlich dokumentiert, es gibt auch noch eine Bluetooth-Variante mit 
eingebautem Akku (derzeit nur als Lochraster ohne Dokumentation und mit 
etwas anderer Pinbelegung), die ich bei Bedarf noch dokumentieren kann.

Die Liste der programmierbaren Devices umfasst derzeit etwa 400 Typen, 
wobei teilweise auch generische dabei sind (z.B. STM32F0xx-32K), die 
meherere Typen abdecken.
Programmiert werden können:

- Atmel AVR (SPI)
- Atmel ATxmega (PDI)
- Cypress PSOC4 (SWD)
- Microchip PIC10xx/PIC12xx/PIC16xx
- Microchip PIC18xx
- Microchip dsPIC33xx
- NXP/Freescale MPC56xx (BAM)
- NXP/Freescale HCS08
- NXP/Freescale HCS12(X)
- Renesas R8C
- Renesas 78K0R
- Renesas RL78
- ST Micro SPC56xx (BAM)
- ST Micro ST7FLITE
- ST Micro STM8 (SWIM)
- ST Micro STM32 (SWD)
- TI MSP430 (SBW)
- TI CC2540/1
- XILINX XC9500/XL
- Atmel Dataflash (AT45DBxx)
- SPI-Flash (25xx)
- I2C-EEPROM (24xx)

Die Liste ist fest im Programm integriert (über Header-Files), ich habe 
mir sie bis jetzt einfach erweitert und neu compiliert, wenn es nötig 
war. Eine Auslagerung in eine externe Datei ist derzeit nicht 
vorgesehen, das Projekt war eigentlich auch nie zur Veröffentlichung 
geplant...

Jörg

[Sven K. (svenk)]

Hallo Jörg,

Wahnsinn wieviel Arbeit Du in den Programmer gesteckt hast.
Vielen Dank dass Du das Projekt veröffentlichst.

Einen kleinen Schaltungsfehler habe ich gefunden: der 10k Widerstand um 
den AVR ist in der Zeichnung kurzgeschlossen.

Gruß Sven

[Joerg W. (joergwolfram)]

Danke für den Hinweis, ich habe das korrigiert und gleich noch ein 
Changelog mit auf die Seite gemacht. Der andere Anschluss des 
Widerstands muss natürlich an PA3. Damit wird die Device-Spannung 
gemessen, wenn sie einen gewissen Wert übersteigt, wird VDD auf Pin2 der 
Leiste nicht angesteuert. Über die Schottky-Diode werden dann ggf. die 
Pegel auf die der externen Spannungsquelle angehoben.

Was momentan noch fehlt, sind die dsPIC30. Der Code dafür ist auch schon 
drin, lediglich die Device-Definitionen fehlen. Werde ich aber demnächst 
noch ergänzen.

Jörg

[Axel S. (a-za-z0-9)]

Nett. Und sehr vorbildlich alles mit Quellcode. Werde ich mir bei 
Gelegenheit mal näher ansehen.

[Thomas W. (diddl)]

Tolles Projekt, danke! ?

[Joerg W. (joergwolfram)]

Es gibt ein kleines Update (V1.26). Es sind ein paar Bugfixes dabei, 
beim MSP430 kann man jetzt festlegen, ob das INFO-A Segment mit gelöscht 
werden soll. SPI-Flashes können jetzt auch im Quad-Mode angesprochen 
werden, das bringt etwas mehr Geschwindigkeit, insbesondere beim 
Lesen/Verify. Außerdem kann man jetzt 3D-Magnetfeldsensoren (MLX90363) 
direkt auslesen. das Ganze wieder unter:

http://www.jcwolfram.de/projekte/uprog2/main.php

Jörg

[Joerg W. (joergwolfram)]

Nach längerer Zeit gibt es wieder mal ein Update. Hinzugekommen sind 
SPI-EEPROMs (AT25010...) und  Programmierung der SPC56xxx über JTAG. 
Daneben gibt es noch ein paar Bugfixes und Ergänzungen, z.B. Erase und 
Programm für die MSP430F5xxx wobei letzteres noch relativ langsam ist, 
da ich die Register noch direkt über SBW beschreibe.

Und es gibt einen Funktionsgenerator, einstellbar von 153Hz bis 2,5MHz. 
Dabei stehen neben der eingestellten Frequenz auch noch geteilte (1/2, 
1/4, 1/8, 1/16 und 1/32) zur Verfügung.
Mittelfristig geplant ist ein Web-Interface für die meisten Funktionen 
und ein kleiner Logik-Analysator mit max. 1 MHz Abtastrate. Über das 
Webinterface lässt sich zur Zeit nur der Frequenzgenerator steuern, dazu 
wird der Webserver mit

uprog2 WSERVER

gestartet (Programmer muss angeschlossen sein) und im Browser die Seite 
http://localhost:48512 aufgerufen. Im Moment ist das Ganze aber nur 
experimentell, da ich für mich selbst das Webinterface eigentlich (noch) 
nicht brauche.

Jörg

[Zweifel (Gast)]

Wenn es noch eine Windows Oberfläche dafür gäbe, wäre das der beste 
Programmer, den es gibt!

[bingo (Gast)]

Tolles Teil, absolut!

Auf der Seite http://www.jcwolfram.de/projekte/uprog2/reference.php 
scheint mir bei 25.1 die Signalbelegung unvollständig zu sein.

Gibt es auch ein Layout für ein PCB?

[Vancouver (Gast)]

Cooles Projekt und sorgfältig dokumentiert, Respekt.

Wäre es prinzipiell möglich, das Teil basierend auf einen Arduino nano 
aufzubauen (AtMega328)? Oder ist ein AtMega644 zwingend erforderlich? 
Man könnte sonst ein kleines Shield mit den notwendigen diskreten 
Bauteilen draufstecken und würde sich den Aufbau des Prozessorsystems 
sparen, die Nanos gibts ja beim Chinesen fast umsonst. Anpassungen der 
Software wären natürlich zu machen.

[Joerg W. (joergwolfram)]

Eine Windows-Version wird es von mir nicht geben. Dazu müsste ich mich 
damit beschäftigen, dafür ist mir aber meine Zeit zu schade und der 
Mehrwert wäre Null (Ich benutze kein Windows). Beim AX81 ließen sich die 
Programme via MinGW relativ einfach übersetzen, hier müsste man aber das 
Konzept zum großen Teil überarbeiten (forking, shared memory). Und 
selbst dann hat man "nur" ein Kommandozeilentool und keine grafische 
Oberfläche.

Eine Idee wäre, das Projekt auf einen Raspberry Pi zu portieren (mit 
direkter Kommunikation über UART) und dazu ein minimales, schnell 
bootendes Image zu erstellen. Mit entsprechend ausgebautem Webinterface 
könnte man dann per Ethernet oder WLAN programmieren und wäre vom OS 
unabhängig.

Das Problem mit der Pinbelegung habe ich korrigiert. Es lag an meinem 
Latex->HTML Konverter, da hat der Tabellenumbruch gefehlt. In der 
PDF-Doku war es richtig drin.

Layout für ein PCB gibt es schon (gEDA PCB), das kann ich auch 
hochladen. Allerdings habe ich teilweise Bauteile genommen, die halt 
sich halt gerade in der Bastelkiste befunden haben. So sind zum Beispiel 
die FETs total überdimensioniert, aber ich hatte halt zu dem Zeitpunkt 
nix passenderes da. Und auch beim Doppel-OPV musste ich auf einen 
anderen Typ gehen, da der original vorgesehene defekt war und ich keinen 
neuen kaufen wollte. Daher auch die Drahtbrücken in dem Bereich.


Das ursprüngliche Projekt lief sogar auf einem Mega168/Mega328P, war 
aber sehr eingeschränkt. Die aktuelle Version belegt aber bei mir 
inzwischen 52K Flash. Also müsste ein Teil der unterstützten Typen 
wegfallen. Außerdem müsste man generell die Blockgröße ändern, da sonst 
der RAM nicht ausreicht. Also müsste man noch eine zweite PC-Version 
pflegen oder eine Programmer-Erkennung nebst Blockgrößen-Umschaltung 
einbauen. Und da ich die Libftdi verwende, würden Arduinos mit anderem 
USB-Seriell Wandler auch nicht gehen.


Jörg

[bingo (Gast)]

Es gibt den Arduino Mega mit 128k, der müsste doch auch gehen, hat einen 
FT232 an Bord. Oder gleich einen Arduino Mega 2560 (die haben aber meist 
einen CH340 drauf, der wird aber von Linux verstanden).

[Andreas R. (daybyter)]

Wenns billig sein soll einen stm32f103 ? Braucht mal aber wohl 
Levelshifter.

[Joerg W. (joergwolfram)]

Sicher könnte man zumindest Teilfunktionen auf einen Arduino portieren. 
Aber da geht es schon los beim Quarz. Der UPROG2 hat 20MHz, Arduino 
16MHz. Einfach anpassen ist nicht, da z.B bei allen seriellen 
Protokollen das Timing über die Anzahl der Takte geht. Und auch die 
Spannungsversorgung müsste angepasst oder auf die 3,3V/5V Umschaltung 
verzichtet werden.

Auch wenn der CH430 unter Linux als serieller Port ansteuerbar ist, über 
die libftdi lässt er sich meines Wissens nach nicht ansteuern. Die habe 
ich aber gebraucht, weil ich über den seriellen Port die 1,25MBps nicht 
gescheit hinbekommen habe. Da hat sich der Rechner hin und wieder 
verschluckt, trotz RTS-Auswertung im Controller. Mit der libftdi kann 
ich über chunk_size und latency_timer das Verhalten an meine 2K-Pakete 
viel besser anpassen. Auch bei Bluetooth gehe ich direkt über ein Socket 
und nicht über /dev/rfcommxx.

Und, da bin ich mir ziemlich sicher, sobald das Projekt auf einem 
Arduino läuft kommen früher oder später Forderungen, dass der Quellcode 
auch mit der Arduino-IDE übersetzbar und flashbar ist...


STM32: Bevor ich über 20000 Zeilen Assemblercode von AVR nach Thumb2 
übersetze, fallen mir sicher sinnvollere Projekte ein :-)

Jörg

[bingo (Gast)]

Danke für die Erläuterungen, ist verständlich.

[Joerg W. (joergwolfram)]

Kurz vor Weihnachten gibt es noch ein kleines Update auf Version 1.29. 
Neben ein paar Fehlerbereinigungen (Data-Flash bei den S12XE lag an der 
falschen Adresse) habe ich u.a. die Trimm-Funktion für die HCS08 
verbessert. Das Trimmen des internen Oszillators dauert jetzt zwar etwas 
länger, dafür ist es genauer und die Frequenz lässt sich auf 8, 9 oder 
10MHz einstellen.

Außerdem werden jetzt einige V850 / RH850 von Renesas unterstützt.


Bei den Sensoren ist der Rotary-Magnetsensor MLX90316 sowie der 
Drucksensor LPS25H dazugekommen, hier lassen sich Druck und Temperatur 
auslesen. Die Sensoren habe ich mit dazugenommen, auch wenn sie sich 
meist nicht programmieren lassen. Aber es hat mir schon das Debugging 
bei anderen Projekten erleichtert.


http://www.jcwolfram.de/projekte/uprog2/main.php


Jörg

[Philipp Klaus K. (pkk)]

Wie wäre es mit stm8flash-Unterstützung?
Dann könnten STM8-Anwender den UPROG2 mit ihnen vertrauter Software 
nutzen.

Philipp

[Joerg W. (joergwolfram)]

Direkt über stm8flash wird es wohl nicht gehen, da die Kommunikation 
zwischen Programmer und Steuerprogramm nicht direkt sondern über einen 
Daemon erfolgt.
 Man könnte aber das Steuerprogramm (uprog2) dahingehend erweitern, dass 
es sich wie ein stm8flash verhält, wenn es als stm8flash aufgerufen wird 
(über Softlink). Wenn dazu dann noch parallel das "richtige" stm8flash 
installiert ist/wird, kann es aber zu Problemen und Missverständnissen 
führen, gegen die die abweichende Syntax von uprog2 wahrscheinlich das 
kleinere Übel ist.


Jörg

[bingo (Gast)]

Die PIC18xxxx (ohne J und K) z.B. 18F2455 18F2550 etc. werden wohl nicht 
unterstützt?

[Joerg W. (joergwolfram)]

Wahrscheinlich fehlen sie nur in der Liste. Ich habe halt erstmal nur 
das eingetragen, was zu meinem "Mustern" irgendwie ähnlich war. Aber bei 
den PICs scheint es ja wohl hunderte von Typen zu geben.
Wenn man einen Typ mit gleicher Speicherausstattung nimmt und ii (ignore 
ID) als Parameter mit angibt, sollte es auch so gehen. Ich mache fast 
nichts mit PICs, wenn Du mir eine Liste mit gängigen Typen auflisten 
würdest, kann ich sie beim nächsten Release mit aufnehmen.

Jörg

[Stephan (Gast)]

MS hat ja in Win10 eine Funktion eingebaut das Linux Programme direkt 
laufen können. Hat das Jemand schon mit der Soft hier versucht ?

[MaWin (Gast)]

Zweifel schrieb:
> Wenn es noch eine Windows Oberfläche dafür gäbe, wäre das der
> beste Programmer, den es gibt!

Schreib sie doch, ist doch alles dolumentiert.

[Peter S. (petersieg)]

Eine schöne Weihnachtsüberraschung wäre es, wenn jemand eine Platine 
dazu erstellt (für mich gerne auch als Through hole - muss aber nicht) 
und das Layout zum Bestellen bei den günstigen CN Lieferanten hier 
einstellt.
Gerne auch mit Sammelbestellung hier über das Forum ;-)

(Man darf sich ja aktuell gerade auch mal etwas wünschen ;-)

Peter

[bingo (Gast)]

Joerg W. schrieb:
> wenn Du mir eine Liste mit gängigen Typen auflisten
> würdest, kann ich sie beim nächsten Release mit aufnehmen.

Von den PICs gibt es generell sehr viele Typen, m.W. mehrere Hundert.

In der 18er Serie gibt es die J und K-Typen, da hast Du ja schon einige, 
die laufen aber nur bis 3.6 Volt. Die Typen 18Fxxx und 18Fxxxx (ohne J 
oder K) sind 5-Volt-Typen und werden von Bastlern oft benutzt, wobei die 
Serie mit 3 Zahlen schon etwas antik sind, da wird geleg. noch der 
18F242 verbaut, aber auch dafür gibt es neuere Typen in der Serie mit 4 
Zahlen, auch da sehr viele Varianten.

Sehr oft verbaut werden 18F1320, 18F2455, 18F2550, 18F2620 sowie ihre 
Pendants die statt der führenden 2 eine 4 haben und statt 18 Pins dann 
40 bzw. 44 Pins haben.

Eine gute Übersicht findest Du unter 
http://www.sprut.de/electronic/pic/18f.htm und 
http://www.sprut.de/electronic/soft/usburn/usburn.htm#typen

[Peter S. (petersieg)]

(Ich weiß, ein wenig off topic für uprog2 - trotzdem evtl. für den einen 
oder anderen hilfreich.. und für uprog2 hoffentlich nicht störend.. 
sonst bitte verschieben.)

Ich bin auch auf der Suche nach Programmierwerkzeugen unter Linux. 
USBasp mit avrdude klappt einwandfrei.

Für meinen K150 Kitrus PIC Programmer aus CN für 7€ läuft die Win$ 
Software aber nicht unter Wine. Hier gibt es es ein Python Script was 
funktioniert:

https://eliasandrade.wordpress.com/2015/01/20/como-usar-o-gravador-pic-k150-no-linux/

Und hier wird ein Parallel EEprommer mit Arduino Mega2560 und Adapter 
vorgestellt (auch dafür wird unten in den Kommentaren ein Python Script 
vorgestellt):
http://danceswithferrets.org/geekblog/?p=496
Link zu Python Script:
http://kildall.apana.org.au/~cjb/Arduino/megaprogrammer.py

Peter

[Martin (Gast)]

Schönes Projeket.

Wenn du schon den Renesas R8C unterstützt kannst du den Code auch auf 
die M16C erweitern, ist ja jast das Gleiche. Der Speicherbereich 
(Adressen) ist ein anderer. Ich weiß nicht aus dem Kopf ob es noch 
andere Unterschiede gibt.

[Joerg W. (joergwolfram)]

Problem ist halt, dass ich keinen M16C hab, um das ausprobierem zu 
können. An sich geht das ja über einen Bootloader, dessen 
Kommando-Interface bei R8C/M16C/M32C weitestgehend gleich ist. Also 
müsste man wohl nur ein paar neue Typen mit entsprechenden 
Adressbereichen in die Tabelle einfügen.

Für das nächste Release sind erstmal ein paar weitere PIC-Typen geplant, 
dazu ein paar Bugfixes und, wenn es klappt, der CC2640 von TI. So 
langsam wird auch das Flash vom Controller voll, so dass demnächst auch 
ein bisschen "Aufräumarbeit" ansteht.

Jörg

[Uschi (Gast)]

Gibt es denn dafür schon eine Platine bzw. Gerber-Files, ich mag die 
Ätzerei nicht selbst machen.

[Joerg W. (joergwolfram)]

Von mir nicht, ich ätze meine PCBs noch selbst. Ich kann die .pcb (gEDA 
PCB) zur Verfügung stellen und ggf. ein PNG mit als Belichtungsvorlage. 
Die Bluetooth-Variante habe ich auf Lochraster aufgebaut. Und mehr 
Programmer brauche ich momentan nicht.

Da sie SW nicht unter Windwows läuft, ist der Kreis der Interessenten 
halt eher klein. Aber vielleicht findet sich ja jemand, der Zeit und 
Lust dazu hat, ein entsprechendes Layout zu erstellen.

JUörg

[Joerg W. (joergwolfram)]

Es gibt wieder einmal ein Update (V1.30). Neben ein paar Bugfixes können 
jetzt auch die STM32L4xx und der CC2640 programmiert werden. Außerdem 
habe ich die PIX18F2xxx/PIC18F4xxx mit aufgenommen.

Außerdem gibt es ein neues Feature (wofür man leider das gesamte Image 
mit einem anderen Programmer flashen muß):
 Es lassen sich, per Software umschaltbar, 2 Devices ohne Umstecken 
programmieren. Dazu wird an den Programmierspannungsausgang (Pin 9) 
einfach ein 12V Relais angeschlossen. In den Programmierbefehl für das 
zweite Device muss dann einfach ein "d2" eingefügt werden. Bei den PICs 
geht das leider nicht, da hier die Programmierspannung benötigt wird.


Das Ganze wie üblich unter:

http://www.jcwolfram.de/projekte/uprog2/main.php

Jörg

Nachtrag: Die Seite ist jetzt (experimentell) auch unter

http://tcrkkpvqapdku6vi.onion/index.html

erreichbar

[Soul E. (Gast)]

Joerg W. schrieb:

> Problem ist halt, dass ich keinen M16C hab, um das ausprobierem zu
> können. An sich geht das ja über einen Bootloader, dessen
> Kommando-Interface bei R8C/M16C/M32C weitestgehend gleich ist.

Der M16C verwendet ein paar Leitungen mehr als der R8C. Letzterer wird 
eigentlich nur über MODE und RESET programmiert.


Eine Platine mit MC3062CF8TGP drauf kannst Du haben falls Dir das 
irgendwie weiterhilft.

[Joerg W. (joergwolfram)]

Darauf würde ich später gerne zurückkommen, momentan habe ich aber noch 
2-3 größere "Projektbrocken" herumliegen, die auch mal fertig und 
dokumentiert werden wollen ...

Jörg

[Joerg W. (joergwolfram)]

Es gibt wieder mal ein neues Update, V1.31.

Neu hinzugekommen sind die S32K von NXP (früher Freescale). Das sind 
automotive Mikrocontroller mit einem Cortex M0+ bzw. M4F Kern.

Des Weiteren gab es bei den SPI-Flashes Fehler beim Quad-Mode, das 
scheint jetzt weitestgehend behoben zu sein. Es gibt aber immer noch 
gelegentlich das Problem, dass hin und wieder bei großen Flashes die 
Verbindung zum Programmer abbricht. Das tritt aber nur bei der 
USB-Variante auf. Eventuell "verschlucken" sich der FTDI oder der 
Treiber, mit 1,25MBps läuft das Ganze ja ganz flott und ich habe kein 
Handshake eingebaut. Das muss ich ggf. noch ergänzen. Ich habe jetzt als 
Workaround ein kleines Delay eingebaut, damit tritt der Fehler 
wesentlich seltener auf.

Die Webserver-Funktion habe ich wieder entfernt, da ich sie nicht mehr 
benötige und demzufolge auch nicht mehr weiterentwickle. Eigentlich 
sollte das Teil einer IDE sein, die komplett im Browser läuft, das 
Projekt habe ich aber inzwischen komplett aufgegeben. Das Projekt liegt 
(immer noch) unter:


http://www.jcwolfram.de/projekte/uprog2/main.php


Jörg

[Joerg W. (joergwolfram)]

Es gibt wieder mal ein neues Update, V1.32

Neu hinzugekommen sind die S9KEA64 von NXP (Freescale), kleinere 
RH850-Typen und PIC16(L)F153xx. Um Platz zu gewinnen, habe ich die 
Bootloader-Sektion verkleinert, dadurch müssen das System neu 
aufgespielt und die Fuses neu programmiert werden.

Ansonsten ist noch ein Bugfix für ältere AVRs ohne Ready/Busy Bit dabei, 
diese wurden sonst u.U. nicht richtig programmiert.

Link wie gehabt...

Jörg

[Ralf E. (r_e)]

Hallo Jörg,

was ist den eigentlich aktueller, das weiter oben gepostete Layout 
(.pcb) oder die Schaltung auf deine Website? Wobei sich diese Layout ja 
auch noch vom Bild des Programmers unterscheidet.

Ich wollte mir gerade das Layout neu erstellen, dabei sind mir 3 
Unterschiede aufgefallen:

* im Layout hast du zusätzlich noch einen Kondensator zwischen VPP und 
GND
* im Layout fehlt der 100nF am FT232_3V3OUT (17) (Im Bild ist der Pfeil 
2Pins zu weit unten)
* der Schaltungsteil zur Programmierspannungs-Erzeugung hängt im Layout 
vor der Sicherung direkt an +5V USB

LG
Ralf

[peg (Gast)]

Joerg W. schrieb:
> Um Platz zu gewinnen, habe ich die Bootloader-Sektion verkleinert,

Ist denn der 644(pa) zwingend, das System müsste doch auch auf einem 
1284(P) laufen ?

[Karl I. (Gast)]

Ich finde die Tatsache, dass endlich ein vernünftiges PCB-Design 
existiert sehr interessant. Ich habe das mal auf einer 
Experimentier-Platine realisiert, aber das ist ja nicht befriedigend. 
Gibt es das neue PCB auch als Gerber o.ä., dann könnte man eine 
Sammelbestellung organisieren.

[AVR-Bastler (Gast)]

Den hatte ich noch gar nicht gesehen.
Schick.
Wenn er jetzt noch updi für die neuen Attiny könnte...

[Karl I. (Gast)]

AVR-Bastler schrieb im Beitrag #5711473:
> Wenn er jetzt noch updi für die neuen Attiny könnte...

Wenn es speichermassig beim 644 schon gng wird, ist ein Attiny doch 
mindestens 1 Hausnummer unterhalb der Anforderungen: die Attiny hören 
z.Zt. bei 16/2 kB auf, der 644 ist mit 64/4 kB schon kanpp dran ...

[Joerg W. (joergwolfram)]

Die Schaltung sollte eigentlich das Aktuellste sein. Auf dem Bild ist 
mein "Prototyp", da sind auch noch ein paar Drahtbrücken drauf (beim 
OPV). Von diesem Prototypen habe ich dann die Schaltung abgezeichnet.

Der Kondensator an 3V3OUT ist nicht zwingend notwendig, aber sinnvoll, 
den an VPP hatte ich nur vorsichtshalber vorgesehen.
Für die VPP-Erzeugung hatte ich eigentlich eine zweite Polyfuse 
vorgesehen, letztendlich ist ein 0-Ohm Widerstand drauf gekommen, weil 
gerade zur Hand. Und dann ist es halt so geblieben...

Sicher wäre auch eine Variante mit dem Mega1284P möglich, die müsste 
aber gesondert gepflegt werden, da der Bootloader- und Sytembereich dann 
an anderen Adressen liegt. Es ist aber für mich einfacher, die Software 
zu ändern, als einen neuen Controller zu kaufen und aufzulöten UND die 
Software zu ändern.

Wenn mir ein ATTiny mit UPDI unterkommt, werde ich die sicher mit 
einpflegen.

Jörg

[Uschi (Gast)]

Karl I. schrieb:
> Gibt es das neue PCB auch als Gerber o.ä., dann könnte man eine
> Sammelbestellung organisieren.

Gerber wäre toll.

@Ralf

Auf Deinem Board sind einige einzelne Lötaugen, wozu sind die gut?
Welchen Quarz (Bauform) verwendest Du?
Pin17 des FT232 sollte laut FTDI-Datenblatt bestückt werden.

@Karl

Organisierst Du eine Sammelbestellung (sofern Joerg und Ralf 
einverstanden sind)?

Danke an alle!

[Ralf E. (r_e)]

Hallo,

erst mal zur Klarstellung, das ist nicht mein Board.
Der Entwurf von Hardware und Software ist von Jörg. Das Bild zeigt das 
Layout aus der Datei uprog2_08.pcb von Jörg.

Ich bin gerade dabei, das neu zu layoten, um mir Platinen machen zu 
lassen, selber ätzen tu ich mir nicht mehr an.

Wenn fertig, dann werde ich das natürlich auch hier zur Verfügung 
stellen, evtl. fallen auch gleich noch ein paar Platinen ab, die 
Chinesen liefern ja sowieso nicht einzeln.


Jetzt zur Schaltung.

Jörg schreibt auf seiner Website,  er hat an Bauteilen genommen, was 
gerade da war :-), z.B: die Mosfets im TO252 Format, die riesige Spule 
oder die ausgefallenen LEDs.
Mach ich auch meist so, allerdings möchte ich im Layout doch Teile 
verwenden, die auch leicht zu bekommen sind (Reichelt,...).

Schaltplan hab ich mal angehängt, ich hoffe ich hab bei der schnellen 
Übernahme nicht noch was vergessen oder verwechselt.

Aktuell ist da noch nichts fix, ihr könnt noch Wünsche äußern.

* SMD soweit möglich komplett in 0805.
* USB-Teil hab ich hier jetzt von einem vorhanden Layout übernommen, 
spart Arbeit, muss ja nicht kompl. bestückt werden (LEDs,..).
* Mini-USB bleibt, ist einfach haltbare als die Micro-Teile
* Mosfets: Da hätte ich IRF7410 da, halte ich allerdings auch für 
übertrieben. Was denkt Ihr über z.B. den IRLML2246, geeignet?
* Induktivität, sollte was kleineres reichen, Typ ??
 (* Schotky-Dioden dito, muss ich noch nach nem Typ schauen 
(BAT54/MBR520/BAT46 ?), oder hab ihr da welche, die ihr sowieso immer 
verwendet und deshalb vorrätig habt /verwenden möchtet.
* Stecker, evtl zusätlich zur 9pol. Stiftleiste noch ein 5x2 
Wannenstecker, damit lassen sich leicht verpolungssichere Adapterkabel 
machen.

LG

[Stephan S. (uxdx)]

Wannenstecker für ISP hielte ich für übertrieben, braucht viel Platz, 
wird damit ja nur 1x programmiert, Updates dann über USB

Für den Programmierstecker wäre Micromatch chic, gibt es auch bei R..., 
Flachkabel haben bei den PICs aber den Nachteil, dass die CLK-Leitung 
sehr empfindlich gegen Störungen ist (siehe 
http://sprut.de/electronic/pic/icsp/icsp.htm, auch eigene Erfahrung), da 
müssen GND daneben

USB wäre mir egal, mini oder micro

IRF7410 wäre für 16A gut, lieber was kleineres

Schottky-Diode dürfte unkritisch sein, ich verbaue gerne BAT43/46/48, 
obwohl die oft im Mini-Melf sind, gibt es aber auch in anderen 
SMD-Bauformen. Bitte keine 3-poligen ...

Quarz als 5x7mm oder 3x5mm (2x2.5mm wäre schon echt winzig), alle bei 
R... erhältlich

Induktivität z.B. L-1616FPS 150µ oder L-1210F 150µ von R...

[Ralf E. (r_e)]

Wannenstecker nicht für den ISP des Programmers, sondern zusätzlich zur 
einreihigen 9pol. So kann man sich ein paar Adapterkabel für die 
verschiedenen Anwendungen machen.

Micromatch verwende ich normalerweise auch für den ISP, ist allerdings 
nicht so weit verbreitet.

[Stephan S. (uxdx)]

noch ein P.S.

Der TLV272 als Präzisions-OPV für die Programmierspannung der PICs wäre 
mir vom Spannungsbereich zu klein, VPP kann immerhin bis 14V betragen 
plus Sicherheits-Marge wären dann 18-20V besser, z.B. LM6132, allerdings 
deutlich teurer

[Ralf E. (r_e)]

Der alternative OPV ist ja pinkompatibel, da kann jeder verwenden, was 
er will.

Und wer PICs programmiert, muss ja kein Flachbandkabel verwenden (oder 
kann auftrennen).

Wenn du auch Micromatch für ISP verwendest, welch Belegung hat sich denn 
bei dir durchgesetzt? Pin 1 bei der verlängerten Nase (so hab ich das 
bis jetzt gehandhabt) oder Pin 1 auf der anderen Seite (wie in einigen 
Micromatch-Datenblättern).

[Stephan S. (uxdx)]

Pin 1 ist bei mir an der Nase, weiblich ist auf Platine, männlich am 
Kabel. Leider ist es im Datenblatt bei Reichelt genau umgekehrt.

Ich nehme auch oft Pogo-Pins (auf einer kl. Hilfsplatine) zum 
programmieren, das spart den Stecker auf der Platine.

[bingo (Gast)]

Stephan S. schrieb:
> Der TLV272 als Präzisions-OPV für die Programmierspannung der PICs wäre
> mir vom Spannungsbereich zu klein, VPP kann immerhin bis 14V betragen
> plus Sicherheits-Marge wären dann 18-20V besser, z.B. LM6132, allerdings
> deutlich teurer

Den TLV272 scheint es von verschiedenen Herstellern zu geben. Bei TI 
sind es 16V, das dürfte reichen; ich habe aber auch schon 5.5V gesehen.

[Renate (Gast)]

ich finde das Projekt SEHR interessant, zumal Sprut seine eigenen 
Brenner aufgegeben hat, er zeigt nur noch die Microchip-Brenner 
http://www.sprut.de/electronic/pic/brenner/, die alten Seiten sind 
völlig weg, sehr schade.

[Joerg W. (joergwolfram)]

Die 9-polige Buchsenleiste ist nicht unbedingt optimal, besonders was 
Verschleißfestigkeit angeht. Nach ca. 4 Jahren habe ich sie tauschen 
müssen, da zumindest die 4-poligen Adapterkabel nicht mehr ordentlich 
gehalten haben. Meine BT-Variante (aus der später die USB-Variante 
entstanden ist) hat übrigens eine 9-pol. D-Sub, daher kommen die 9 Pins.

Für PICs nutze ich einen kurzen Zwischenadapter, ebenfalls für die 
Xilinx CPLDs (damit ich zum Parallel-Kabel kompatibel bin). Bei fast 
allen anderen Projekten nutze ich die Signalfolge vom Programmer und 
komme dadurch mit ein paar 1:1 Kabeln (4,5,6 Pole) aus.

Für Controller und Schnittstellen, die das zulassen, ließen sich auch 
Debug-Funktionen realisieren. Letztendlich habe ich das aber nicht 
weiter verfolgt, da ich selbst mit "indirektem Debugging" besser 
klarkomme. Kleinere Schaltungen lassen sich auch probeweise direkt aus 
dem Programmer betreiben, hier sind die 4 parallelgeschalteten Portpins 
nicht die optimale Lösung, aber in den meisten Fällen reicht es bei mir 
aus. Ansonsten wird ja erkannt, wenn bereits Spannung an der Baugruppe 
anliegt.

Jörg

[Ralph S. (jjflash)]

..... aaaalso wenn jemand eine Platine beim Chinamann fertigen läßt: 
Just for fun um die Arbeit von Jörg zu sehen würde ich eine nehmen.

[Np R. (samweis)]

Joerg W. schrieb:
> Wenn mir ein ATTiny mit UPDI unterkommt, werde ich die sicher mit
> einpflegen.

Das wäre wirklich sehr schön.

Ich würde Dir ja gerne einen in einen Briefumschlag stecken - aber 
leider wohne ich nicht in Deutschland, und mit den neuen Regelungen für 
den internationalen Postversand müsste ich den kleinen Käfer in ein 
Paket werfen.

Bei TME z.B. gibt's den Attiny212 oder Attiny412 ab ca. 60cent. Die 
größeren ab 75cent.

Falls es hilft - Code gibt's auf GIThub: jtag2updi, STK2UPDI (beide C++ 
auf Atmega328), pyupdi (Python), oder updiprog (C).

[foobar (Gast)]

Btw, in dem Schaltplan weiter oben (uprog2.png) ist der MOSFET Q2 falsch 
- sollte nen N-Channel sein. Und was soll des Gehampel dahinter mit dem 
OpAmp?

[Ralf E. (r_e)]

Den Fehler mit dem Mosfet hatte ich auch schon bemerkt, war einfach ne 
Unachtsamkeit von mir beim Abzeichne der Schaltung von Joerg.

Mit dem OP wird die durch den Aufwärtswandler erzeugte 
Programmierspannung (für PICs) gemessen und geschaltet.

[Renate (Gast)]

Ralf E. schrieb:
> Mit dem OP wird die durch den Aufwärtswandler erzeugte
> Programmierspannung (für PICs) gemessen und geschaltet.

Eigentlich wäre der gar nicht nötig, sprut hat das ganz ohne OPV 
einfacher gestaltet

[Renate (Gast)]

über L1, D1, Q2 und C5 wird Vpp erzeugt und über R4 und R5 gemessen.

Q3/Q4 und Q5/Q6 sind nur dazu da, um Vpp je nach Pin-Layout an den 
Testsockel zu führen. Bräuchte man beim uprog2 nicht.

[foobar (Gast)]

> Q3/Q4 und Q5/Q6 sind nur dazu da, um Vpp je nach Pin-Layout an den
> Testsockel zu führen. Bräuchte man beim uprog2 nicht.

Abschalten möchte man die Vpp evtl ja doch, ein Pärchen wäre also schon 
angebracht (gerne auch MOSFETs). Ebenso R9 für ein definiertes Low.

Insgesamt gefällt mir die Schaltung auch besser - statt zwei OpAmps zwei 
08/15-Transistoren ...

[Joerg W. (joergwolfram)]

> statt zwei OpAmps zwei 08/15-Transistoren ...

Naja, so viel Platz braucht ein SO8 Dual-OPV auch nicht...

Eher finde ich die Lösung mit den 4 parallelgeschalteten Pins für die 
Spannungsversorgung im Nachhinein als nicht optimal. Aber es 
funktioniert.

Jörg

[Stephan S. (uxdx)]

Joerg W. schrieb:
> Naja, so viel Platz braucht ein SO8 Dual-OPV auch nicht...

Viele Wege führen nach Rom ...

[Ralf E. (r_e)]

@Joerg W.

...Eigentlich wollte ich an deiner Schaltung nicht so viel ändern, 
sondern nur das Layout auf leicht verfügbare Bauteile anpassen und 
Platinen fertigen lassen....

Ein zusätzlicher Mosfet zum schalten der Spannungsversorgung hätte aber 
sicher noch Platz und würde auch ohne Softwareänderung funktionieren.
Welchen der 4 Ports verwendest du denn zur Spannungserkennung?

[Joerg W. (joergwolfram)]

> Welchen der 4 Ports verwendest du denn zur Spannungserkennung?

Keinen. Die Spannung geht über einen 10K/1K Teiler an PA3. Falls doch 
Änderungen notwendig sind ist das i.A. auch kein größeres Problem, man 
könnte z.B. PB0 auf Masse legen damit die Firmware das erkennt.

Jörg

[Ralf E. (r_e)]

hier mal mein aktueller Layout-Stand, Bestückungsdruck usw. muß 
natürlich noch überarbeitet werden.
9- und 10-pol. Stiftleiste Belegung wie bei Joerg, 6-pol. AVR-ISP 
Standard

[Ralf E. (r_e)]

Joerg W. schrieb:

> Änderungen notwendig sind ist das i.A. auch kein größeres Problem, man
> könnte z.B. PB0 auf Masse legen damit die Firmware das erkennt.

Wäre da wahrscheinlich doch nötig, da einer der 4 jetzt zur 
Spannungsversorgung verwendeten Ports dann Low-Aktiv verwendete werden 
sollte um die Spannung per Mosfet zu schalten.....

[Stephan S. (uxdx)]

Ralf E. schrieb:
> hier mal mein aktueller Layout-Stand,

hübsch, gefällt mir !  (ohne das Routing kontrolliert zu haben)

[  (Gast)]

Ich bin schon eine Weile auf der Suche nach einer Lösung zur 
Programmierung von HCS08 Controllern unter Linux. Das Projekt hier sieht 
nach einem sehr interessanten Programmer aus.

An welche Pins müssen denn die Programmierleitungen für die HCS08
angeschlossen werden? Das hat sich mir aus der vorliegenden 
Dokumentation und einer ersten Durchsicht des Quellcodes bisher nicht 
direkt erschlossen.

Das Kompilieren von uprog2 klappt sowohl auf dem PC als auch auf einen 
RaspberryPi (Version 3) nach einem "sudo apt-get install libftdi1-dev 
libusb-1.0.0-dev libbluetooth-dev" ohne Probleme.

@Joerg W.: Gäbe es Einwände den Code so wie er ist in ein GitHub Projekt 
zu importieren?

Für einen richtigen Test fehlt jetzt noch die Hardware.

@Ralf E.: Falls irgendwo Boardlayouts, Rohleiterplatten oder sogar 
bestückte Boards herausfallen würde ich ggf. Interesse haben.

[Ralf E. (r_e)]

@nbsp;: Die Signalbelegung hat Joerg doch übersichtlich in der 
Typenliste angegeben: 
http://www.jcwolfram.de/projekte/uprog2/reference.php

Das Layout von mir kann natürlich jeder verwenden, soweit Joerg da 
nichts dagegen hat, schließlich stammt der Entwurf ja von ihm.
Übrige LP können wir reden, wenn ich denn mal die erste getestet 
habe.... Falls da dann mehr Interesse besteht evtl. auch 
Sammelbestellung, da sollte dann IMHO aber auch ein paar ct. für Joerg 
abfallen, wird bei anderen Sammelbestellungen hier im Board auch so 
gehandhabt.

Layout ist so ziemlich durch.
Todo: noch zwei passende LogicLevel-Mosfets in SOT23-3 raussuchen...
Beschriftung Rückseite...
Noch mal auf Fehler prüfen...

Im Moment schwanke ich noch bei der Spannungsversorgung für 
angeschlossene Devices, so lassen wie von Joerg vorgesehen über den 644 
oder doch geschaltet direkt aus VDD..... gerade ist die Faulheit noch 
stärker....

[Joerg W. (joergwolfram)]

> @Joerg W.: Gäbe es Einwände den Code so wie er ist in ein GitHub Projekt
> zu importieren?

Eigentlich nicht. Eventuell müsste man vom aktuellen Release einen Fork 
machen. Denn das Problem dabei ist, dass ich meinen eigenen Programmer 
auch auf Arbeit benutze und der noch ein paar Devices mehr kann, was ich 
aber nicht veröffentlichen darf (NDA). In den Quelltexten sind diese 
Familien dann entsprechend gekennzeichnet. Der Release-Erstell-Prozess 
entfernt diese und ersetzt z.B. in der interpreter.asm die 
entsprechenden Aufrufe (man sieht das an den "reserved" Kommentaren), 
bevor alles neu übersetzt und gepackt wird.

Aus der öffentlichen Version lässt sich meine eigene aber nicht mehr 
rekonstruieren, so dass ich zwei Versionen aktuell halten müsste. Da 
müsste ich mir etwas einfallen lassen...

Die Belegungen finden sich in der Doku und werden zusätzlich beim Aufruf 
des Programmers angezeigt. Das funktioniert im Moment aber nur, wenn der 
Programmer angeschlossen ist. Ich habe versucht, ein möglichst 
einheitliches Schema zu verwenden, 1=GND, 2=VCC, 3=RESET, 
4...=Daten/Clock, damit ich so wenig wie möglich "Adapterkabel" 
benötige.

Jörg

[Philipp Klaus K. (pkk)]

Wäre auch Unterstützung für Padauk µC möglich? Fehlt es dazu an 
Spannungen? Die Flash-Varianten sind da wohl etwas weniger anspruchsvoll 
als die OTP.

Philipp

[Joerg W. (joergwolfram)]

> Wäre auch Unterstützung für Padauk µC möglich? Fehlt es dazu an
> Spannungen? Die Flash-Varianten sind da wohl etwas weniger anspruchsvoll
> als die OTP.

Warum nicht? Es gibt wahlweise 3,3 und 5V sowie eine Spannung, die sich 
zwischen ca 5V und 14V einstellen lässt.

Jörg

[Joerg W. (joergwolfram)]

Was mir noch eingefallen ist: Wenn man VCC über einen Transistor 
schaltet, sollte auch ein zweiter Transistor gegen Masse vorhanden sein. 
Hintergrund: Es gibt einige wenige Devices, die den Secure-Status nur 
beim Power-On Reset erfassen. Also muss man zwischen Unsecure und 
Programmieren einen Powerzyklus machen. Ohne Entladen von vorhandenen 
Blockkondensatoren klappt das aber nicht sicher. Und beim folgenden 
Programmaufruf kann es dann vorkommen, dass der Programmer beim 
Wiedereinschalten die Restspannung als externe Versorgung interpretiert.

Jörg

[hm (Gast)]

Hallo

Ich habe versucht mittels uprog2 einen MC9S08 DN 60 zu programmieren, 
das funktioniert aber nicht.

Dieser Controller ist derzeit nicht explizit in der Liste der 
unterstützten Controller aufgeführt. Vielleicht liegt es also daran, 
dass das Programmieren nicht geht?

Bisher wurde der Controller mittels Codewarrior über ein s19-File 
programmiert.

Für uprog habe ich das s19-File mittels srecord in ein Hex-File 
umgewandelt:

srec_cat file.s19 -o file.hex -intel

Anschließend habe ich dieses File mittels

uprog2 MC9S08AW60 -pm file.hex

 bzw.

uprog2 MC9S08AW60 -empm file.hex

 "erfolgreich" programmiert.

Allerdings läuft das Programm nicht.

Testweise habe ich auch den zuvor mittels Codewarrior und s19-File 
geflashten Speicher mittels

./uprog2 MC9S08AW60 -rm orig.hex

 ausgelesen und anschließend dieses Hex-File erneut programmiert um zu 
prüfen, ob eventuell bei der Konvertierung von s19 zu Hex etwas schief 
läuft.
Aber auch dann läuft das Programm nicht mehr.

Vergleiche ich die ausgelesenen Hex-Files nach der Programmierung 
mittels Codewarrior und nach der erneuten Programmierung des 
ausgelesenen Files so sind diese Files großteils gleich, aber nicht 
ganz.

1. Programmierung mittels Codewarrior
2. uprog2 MC9S08AW60 -rm orig.hex
3. uprog2 MC9S08AW60 -empm orig.hex
3. uprog2 MC9S08AW60 -rm test.hex
4. diff orig.hex test.hex

Liegt das Problem eher am unterschiedlichen, nicht unterstützten Typ, 
oder gibt es noch etwas anderes, das ich bisher übersehe?

[Joerg W. (joergwolfram)]

> Für uprog habe ich das s19-File mittels srecord in ein Hex-File
> umgewandelt:

Braucht man eigentlich nicht, denn die UPROG2 Software kann beides lesen 
und auch schreiben. Beim Lesen geht theoretisch sogar gemischt...

Läuft folgendes Kommando fehlerfrei?

uprog2 MC9S08AW60 -empmvm orig.s19

Wenn der Datensatz "secured" ist, kann man das auch mit der Option 'ns' 
abschalten. Dafür wird dann das Byte an 0xFFBF entsprechend modifiziert.

Jörg

[hm (Gast)]

Hallo Jörg,

danke für die schnelle Antwort.

Tatsache, das s19-File wir auch eingelesen. Gestern hatte ich damit 
irgendwie zuerst Probleme, weshalb ich ein Hex-File probiert habe.

Das Ergebnis ist aber auch direkt mit dem s19-File leider noch gleich.

Ich bekomme folgendes mit einem selbst kompilierten uprog auf einem 
RaspberryPi (bei … habe ich gekürzt):

$./uprog2 MC9S08AW60 -empmvm orig.s19

#################################################################################
#                                                                               #
#  UNI-Programmer UPROG2 V1.32         
…
#     0 types in database                                                       #
#                                                                               #
#################################################################################
>> USB programmer is active.

***  can be programmed with:  ***

Version =  1.5
Sysver  =  0011
V-Ext   =  2.9V
V-PROG  =  2.1V
## Action: main flash erase
## Action: main flash program using orig.s19
## Action: main flash verify using orig.s19
## Action: writing SEC to unsecured state

BDM FREQ = 9.0MHz     USED MODE = 9MHz     FCDIV = 0x2d
>> CHECK SECURITY
** DEVICE IS UNSECURED **
ERASE
PROG |**************************************************|
READ |**************************************************|
ERR -> ADDR= 10000  DATA= FF  READ= 84
ERR -> ADDR= 10001  DATA= FF  READ= 00
ERR -> ADDR= 10002  DATA= FF  READ= EA
...
ERR -> ADDR= 118FD  DATA= FF  READ= 00
ERR -> ADDR= 118FE  DATA= FF  READ= 00
ERR -> ADDR= 118FF  DATA= FF  READ= 00

(unexpected error)

Wieso sind die gelesenen Adressen fünfstellig?

---

Der zu programmierende MC9S08DN60 wird auf seinem Board mit 3.3 Volt 
versorgt. Die VDD Leitung vom Programmer ist nicht angeschlossen.

Beim Speicherlayout gibt es Unterschiede. Der MC9S08DN60 hat 60kB (62080 
Bytes) Flash, der MC9S08AW60 hat 63280 Bytes Flash.

Die Memory Map für den MC9S08DN60 findet sich hier auf Seite 38.
https://www.nxp.com/docs/en/data-sheet/MC9S08DN60.pdf
Die Memory Map für den MC9S08AW60 findet sich hier auf Seite 42.
https://www.nxp.com/docs/en/data-sheet/MC9S08AW60.pdf

Hier das Speicherlayout im direkten Vergleich:

MC9S08AW60 / MC9S08DN60 
Direct Page Registers 
Size  112 Bytes / 128 Bytes
Start 0x0000 / 0x0000
End   0x006F / 0x007F

RAM
Size  2048 Bytes / 2048 Bytes
Start 0x0070 / 0x0080
End   0x086F / 0x087F

Flash
Size  3984 Bytes / 2944 Bytes
Start 0x0870 / 0x0880
End   0x17FF / 0x13FF

EEPROM
Size  0 Bytes / 2048 Bytes 
Start ------ / 0x1400
End   ------ / 0x1700

High Page Resisters 
Size  95 Bytes / 256 Bytes
Start 0x1800 / 0x1800
End   0x185F / 0x18FF

Flash 
Size  59296 Bytes / 59136 Bytes
Start 0x1860 / 0x1900
End   0xFFFF / 0xFFFF

Die S19 Datei enthält Daten von 0x1900 bis 0xBD40, was also für den DN 
Typen passen würde. Ich habe zur besseren Lesbarkeit Leerzeichen 
zwischen den Feldern eingefügt.

S0 43 0000 …
S1 23 1900 A7FCC619714C95E701C619704CF7321972201F898BF687E6024C9EE706E603EE 52
…

S1 23 BD20 CD4C6C062805080D10151C1F06201A1E061D0620161E0620021F061D0620041E 45
S1 1B BD40 061C061B0620061E061C061A06A702810002010301FF0000 E2
S1 04 FFBD FF 40
S1 23 FFBF 7EFFFFFFFFFFFFFFFFFFFFFFFF90CDA967A968FFFFFFFFFFFFFFFFA96978C9A9 3A
S1 23 FFDF 6AA96BFFFFFFFFFFFFA1B8FFFFFFFFFFFFFFFFFFFFA096FFFFFFFFFFFFFFFF19 F0
S1 04 FFFF 67 96
S9 03 0000 FC

[Joerg W. (joergwolfram)]

Ich hab mal nachgeschaut, beim AW60 ist der Adressbereich bei mir falsch 
eingetragen, da steht als Startadresse noch 0x8000 wie beim AW32 (den 
ich getestet habe).

Du kannst in die devices_FSL_HCS08.h probeweise den DN60 mit eintragen, 
einfach den letzten Eintrag in der Datei kopieren und anpassen. In der 
dritten Zeile (mit Kommentar "//main flash") einfach Startadresse 
(0x1900) und Länge (0xE700) eintragen und neu kompilieren. Ich kann das 
später mit einpflegen. das nächste Release gibt es wahrscheinlich Anfang 
Mai.

Was mich noch ein wenig stutzig macht, sind die 0 Typen in der 
Datenbank, das scheint aber eine andere Ursache zu haben...

Jörg

[hm (Gast)]

Ich habe jetzt folgendes in devices_FSL_HCS08.h ergänzt.

        "MC9S08DN60",
        1,
        0x1900,0xE700, //main flash
        0x0000,0x0000,
        0x0000,0x0000,
        0x0000,0x0000,
        0x0080,0x0400, //RAM
        0x00000000, //ID
        0x004a,0x0000, //TRIM REG
        0x0000,0x0000,
        0x0000,0x0000,
        0x0000,0x0000,

Leider startet der Code immer noch nicht.

$uprog2 MC9S08DN60 -empmvm  orig.s19
… 
READ |**************************************************|
ERR -> ADDR= F900  DATA= FF  READ= 00
ERR -> ADDR= F901  DATA= FF  READ= 00
ERR -> ADDR= F902  DATA= FF  READ= 00
ERR -> ADDR= F903  DATA= FF  READ= 00
…
ERR -> ADDR= FFFE  DATA= 19  READ= 00
ERR -> ADDR= FFFF  DATA= 67  READ= 00

(unexpected error)

Nachdem ich mich gerade durch den Quellcode grabe noch zwei weitere 
Fragen.

src/modules/writehex.c dürfte für das Schreiben der HEX Dateien 
zuständig sein. Dort wird in den Funktionen write_s19,  write_s29 und 
write_s39 auch der Header "S00441424335" in das srec file geschrieben.

1. Warum heißen die Funktionen s29 und s39 statt s28 und s37.
2. Wenn ich in allen drei Funktionen den Header ändere ist in der beim 
erneuten Auslesen des Speichers in geschriebenen Datei trotzdem der 
unveränderte Header drin.

$uprog2 MC9S08DN60 -rm readout.s19
$cat readout.s19
S00441424335
S32500001900FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE1
…

Auch nach einem definitiven Neustart des Dämons mittels uprog2 KILL und 
einem make clean. Kommt der Header noch woanders her? Den String habe 
ich sonst nur in proto_shadow.s28 prot_shadow.s37 und 
proto_shadow_orig.s37 unter inc/exec/ppc_shadow gefunden.

Der Inhalt der ausgelesenen s19-Datei ist

S00441424335
S32500001900FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE1
…
S3250000F8E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF22
S3250000F9000000000000000000000000000000000000000000000000000000000000000000E1
…
S3250000FFE00000000000000000000000000000000000000000000000000000000000000000FB

Dabei sind tatsächlich die ersten Bereiche alle FF und die letzten 
Bereiche alle 00. Interessanterweise beschwert sich das obige Verify nur 
über die Bereiche mit 00.

[hm (Gast)]

Noch ein Update:
Nach den Änderungen sind die Originaldatei und der Readout "gleicher".
S1 ist aus dem Original, S3 aus dem Readout.

S1 23     1900 A7FCC619714C95E701C619704CF7321972201F898BF687E6024C9EE706E603EE 52
S3 25 00001900 A7FCC619714C95E701C619704CF7321972201F898BF687E6024C9EE706E603EE 50
...
S1 23     BD20 CD4C6C062805080D10151C1F06201A1E061D0620161E0620021F061D0620041E45
S3 25 0000BD20 CD4C6C062805080D10151C1F06201A1E061D0620161E0620021F061D0620041E43
S1 1B     BD40 061C061B0620061E061C061A06A702810002010301FF0000E2
S3 25 0000BD40 061C061B0620061E061C061A06A702810002010301FF0000FFFFFFFFFFFFFFFFE0

Das sieht erstmal biss zur letzten Zeile gleich aus. Dann folgt im 
Readout FF bis

S3 25 0000F8E0 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 22

und dann 00

S3 25 0000F900 0000000000000000000000000000000000000000000000000000000000000000 E1

bis

S3 25 0000FFE0 0000000000000000000000000000000000000000000000000000000000000000 FB

Während nach Originaldatei am Ende noch folgendes stehen sollte.

S1 04 FFBD FF 40
S1 23 FFBF 7EFFFFFFFFFFFFFFFFFFFFFFFF90CDA967A968FFFFFFFFFFFFFFFFA96978C9A9 3A
S1 23 FFDF 6AA96BFFFFFFFFFFFFA1B8FFFFFFFFFFFFFFFFFFFFA096FFFFFFFFFFFFFFFF19F0
S1 04 FFFF 6796
S9 03 0000 FC

Der letzte Speicherteil müsste nach Datenblatt die Vektortabelle sein. 
Diese fehlt scheinbar.

[Joerg W. (joergwolfram)]

OK, ich denke, ich habe die Ursache gefunden. Die Programmierung erfolgt 
immer in 2K-Blöcken die auf 2K Boundaries liegen, und im Fall der 60K 
Varianten klappt das dann logischerweise nicht mehr. Und dann liegen ab 
0xF900 keine Daten mehr...

Du könntest mal versuchen, soweit es möglich ist, den Code für eine 32K 
Version zu übersetzen und als solche zu programmieren. Inzwischen schaue 
ich mal, wie ich die Programmierung/Auslesen von Teilblöcken realisieren 
kann.

Jörg

[hm (Gast)]

>Was mich noch ein wenig stutzig macht, sind die 0 Typen in der
>Datenbank, das scheint aber eine andere Ursache zu haben...

Das kommt wohl fest kodiert hier her:

main.c:80 printf("#     0 types in database                #\n",jj);

Fix:

main.c:80 printf("#     %4i types in database                #\n",jj);

Ähnliches passiert hier:

***  can be programmed with:  ***

in

main.c:207 //printf("ALGO: 0 \n",algo_nr);
main.c:208 printf("***  can be programmed with:  ***\n\n",name,cables[algo_nr]);

Fix:

main.c:207 //printf("ALGO: %i \n",algo_nr);
main.c:208 printf("*** %s can be programmed with: %s ***\n\n",name,cables[algo_nr]);

[Renate (Gast)]

Ralf E. schrieb:
> hier mal mein aktueller Layout-Stand

Gibt es Neuerungen zum PCB ?

[hm (Gast)]

Da habe ich mit dem  meinen Post schreiben zu lange gebraucht.

Danke für den Hinweis mit den 2K-Blöcken. Soweit war ich im Code noch 
nicht.

Ich bin nochmal an den write_s19, write_s29 und write_s39 Funktionen.

Diese werden garnicht benutzt, oder?

Das sreg format wird von

writehex.c:301 int writeblock_open()
...
fprintf(datei,"S00441424335\n");

und

writehex.c:362 int writeblock_data(unsigned long start_addr, unsigned long block_len,unsigned long dest_addr)

geschrieben.

Im Anhang ein diff meiner bisherigen Änderungen falls es von Interesse 
ist.

[hm (Gast)]

Ich hätte auch ein Layout, muss aber noch ein paar Tests machen und dann 
klären, ob ich das veröffentlichen darf, oder vorher noch ändern muss.
Die erste der Platinen programmiert aber offensichtlich (fast) 
erfolgreich einen HCS08 bei 3.3V

[Joerg W. (joergwolfram)]

Danke für die Arbeit und die Hinweise.

Bevor Du dich aber weiter auf Fehlersuche machst, ich habe bei mir einen 
Bug entdeckt. Nicht im Code selbst, aber in dem Script, welches alle 
Devices und Algorithmen für die öffentliche Version entfernt, die dort 
nicht hinein dürfen. Und dort werden die Zeilen an einer Stelle 
fälschlicherweise via printf statt print zurückgeschrieben, was die 
ganzen Formatstrings schon auflöst... Und beim automatischen Test des 
Releases wird nur das Resultat einer "Probeprogrammierung" ausgewertet.

Die write_xxx sind noch "Altrelikte" der Vorgängerversion. Die werde ich 
gleich mit raus werfen.

Ich werde schauen, dass ich die neue Version zum WE vorziehen kann.

Jörg

[Ralf E. (r_e)]

Hab vor einigen Tagen Mal ein paar Platinen bestellt, melde mich, wenn 
die ersten Tests erfolgreich verlaufen...

[hm (Gast)]

Hallo Jörg,

vielen Dank für deinen Support.

Meinst du es wäre möglich beim Schreiben eines Speicherdumps zwischen 
den verschiedenen srec Formaten (16, 24, 32 bit) zu unterscheiden? 
Entweder anhand des Dateinamens (wie das jetzt schon zwischen hex und 
"nicht hex" gemacht wird), oder mittels eines Parameters, oder auch nur 
als Define im Code. Das würde einen späteren textuellen Diff auf die 
Dateien vereinfachen.

Holger

[Joerg W. (joergwolfram)]

Kann ich machen. "s19/S19" wären dann 16 Bit Adresse, "s28/S28" 24 Bit 
Adresse und default 32 Bit Adresse. Was außerhalb der entsprechenden 
Adressbereiche liegt, wird einfach verworfen.

Bei den 60K HCS08 würde ich erst mal den zweiten Flashblock und den 
EEPROM weglassen und nur die "ungerade Startadresse" imlementieren, wäre 
das OK?

Jörg

[hm (Gast)]

SREC Format: Top. Danke!

Der zweite Flash Block ist der an der niedrigeren Adresse?

Flash
Size  3984 Bytes / 2944 Bytes
Start 0x0870 / 0x0880
End   0x17FF / 0x13FF

Der Bereich von 1900 bis FFFF reicht mir erstmal. Das ist ja auch der 
Bereich aus dem S19 File.

Holger

[Holger M. (nezaya)]

So, ich habe mal meinen Login wieder ausgegraben. Der hm (Gast) bisher 
war ich.

Mit Unterstützung meines Arbeitgebers, der Primes GmbH (www.primes.de), 
folgt hier ein erstes Layout (Schaltplan, BOM und Gerber) und ein 
einfaches Gehäuse (STEP) zum 3D Drucken für den uprog2. Das alles in der 
ZIP Datei im Anhang.

Die Spannungsversorgung hat einen FET zum Schalten spendiert bekommen.
Auch hier gilt wie bei Jörg: Die Bauteilauswahl ist dem Vorhandensein 
geschuldet. Es geht sicher besser.

Getestet wurde bisher die grundsätzliche Programmierfähigkeit mit 3.3V.
Der Hochspannungsteil und weitere Teils sind im Schaltplan als nicht 
bestückt gekennzeichnet noch nicht getestet, da ich dafür derzeit keine 
Verwendung habe.

@Jörg: Wenn du möchtest, kannst du das Layout gerne auch bei dir auf die 
Website stellen oder verlinken.

Wenn es Bugs oder Änderungswünsche gibt, werde ich versuchen das in 
Zukunft einzupflegen.

Holger

[Joerg W. (joergwolfram)]

Ich habe jetzt Version 1.33 online gestellt. Für die 60K S08 habe ich 
noch Kommandos für den "lower" Flash eingefügt, konnte sie aber mangels 
Devices nicht testen.
Ansonsten gibt es ein paar Bugfixes und Erweiterungen, insbesondere bei 
den RH850.

Jörg

[Holger M. (nezaya)]

Ich habe die 1.33 heruntergeladen und erfolgreich kompiliert.

Aber irgendwie klappt das Programmieren jetzt nicht mehr.

#  UNI-Programmer UPROG2 V1.33                                                  
...
#   694 types in database                                                       ...
uprog2 daemon is not active, starting daemon and searching for programmer
...

>> USB programmer is active.

*** MC9S08DN60 can be programmed with: (1=VSS  2=VDD  3=RESET  4=BKGD) ***

ERROR CODE 9F

FATAL: CONNECTION TO PROGRAMMER LOST!
   <<< PLEASE RESET PROGRAMMER >>>

Kann es sein, das der Controller auf dem Programmer nicht automatisch 
aktualisiert wird?

Korrektur: Es war ein zweites FTDI Device angeschlossen und das scheint 
uprog2 zu verwirren.

Jetzt komme ich ein Stück weiter und die Programmer Firmware wird 
aktualisiert. Programmieren klappt aber noch nicht.

*** MC9S08DN60 can be programmed with: (1=VSS  2=VDD  3=RESET  4=BKGD) ***

Version =  1.5
Sysver  =  0011
V-Ext   =  2.8V
V-PROG  =  1.9V
PROGRAMMER SYSTEM VERSION: 0011
REQUIRED SYSTEM VERSION:   0012
STARTING UPDATE
Update |**************************************************|
UPDATE DONE
## Action: main flash erase
## Action: main flash program using test.s19
## Action: main flash verify using test.s19

Nach den drei "Action" Zeilen bleibt uprog2 für immer stehen.

Bei einem erneuten Starten bleibt es direkt nach "V-PROG = 1.9V" stehen.

Wenn ich wieder 1.32 verwende, wird die Firmware auch wieder 
"aktualisiert" und ich kann anschließend programmieren (abgesehen vom 
ursprünglichen Problem).

[Joerg W. (joergwolfram)]

Um das Ganze etwas einzugrenzen, würde ich morgen von meinem Programmer 
ein Image ziehen und hier reinstellen. Dann könntest Du mit einem AVR 
Programmer vergleichen, ob das Update erfolgreich war. Solche "Hänger" 
hatte ich eigentlich nur früher, als ich die RTS Leitung nicht 
ausgewertet hatte.

Das mit dem 2.FTDI ist mir auch schon passiert, bei der Entwicklung von 
meinem PDP11-Emulator war das zeitweilig arg nervig, weil ich zum Testen 
immer einen seriellen Port gebraucht habe.

Jörg

[Joerg W. (joergwolfram)]

Ich habe jetzt meinen Programmer ausgelesen, Datei im Anhang. Das Image 
weicht von der öffentlichen Version etwas ab, da es zusätzliche Module 
enthält. Ich habe auch mal probeweise das öffentliche Image auf meinen 
Programmer geflasht und damit einen MC9S08SG16 programmiert.

#################################################################################
#                                                                               #
#  UNI-Programmer UPROG2 V1.33                                                  #
#                                                                               #
#  (c) 2012-2019 Joerg Wolfram                                                  #
#                                                                               #
#  usage: uprog2 device -commands [file/data]                                   #
#         uprog2 KILL                            kill active daemon             #
#         uprog2 LIST                            for device list                #
#         uprog2 device -help                    for device specific commands   #
#                                                                               #
#   694 types in database                                                       #
#                                                                               #
#################################################################################
>> USB programmer is active.

*** MC9S08SG16 can be programmed with: (1=VSS  2=VDD  3=RESET  4=BKGD) ***

Version =  1.5
Sysver  =  0012
V-Ext   =  0.0V
V-PROG  =  4.7V
## Action: main flash erase
## Action: main flash program using main.s37
## Action: writing SEC to unsecured state

BDM FREQ = 8.0MHz     USED MODE = 8MHz     FCDIV = 0x28
>> CHECK SECURITY
** DEVICE IS UNSECURED **
ERASE
PROG |**************************************************|

OK                                                                                                 
./uprog2 MC9S08SG16 -st

#################################################################################
#                                                                               #
#  UNI-Programmer UPROG2 V1.33                                                  #
#                                                                               #
#  (c) 2012-2019 Joerg Wolfram                                                  #
#                                                                               #
#  usage: uprog2 device -commands [file/data]                                   #
#         uprog2 KILL                            kill active daemon             #
#         uprog2 LIST                            for device list                #
#         uprog2 device -help                    for device specific commands   #
#                                                                               #
#   694 types in database                                                       #
#                                                                               #
#################################################################################
>> USB programmer is active.

*** MC9S08SG16 can be programmed with: (1=VSS  2=VDD  3=RESET  4=BKGD) ***

Version =  1.5
Sysver  =  0012
V-Ext   =  0.0V
V-PROG  =  4.7V
## Action: start device


PRESS ENTER TO EXIT 

OK

Eventuell bekommt der PI Timing-Probleme mit der libftdi, dann müsste 
man sich überlegen, die Bitrate von derzeit 1,25MBps für diesen Fall auf 
z.B. 500KBps zu senken. Um nicht noch mehr verschiedene Images zu haben, 
könnte man das z.B. über eine Lötbrücke zwischen PD3 und PD4 erkennen. 
Auf der Hostseite müsste dann in der demon.c der Wert für 
ftdi_set_baudrate entsprechend angepasst werden.

Jörg

[Holger M. (nezaya)]

Ich habe das main-usb.hex File jetzt mittels avrdude auf den uprog 
geschrieben. Seitdem funktioniert es.
Der MC9S08DN60 wird korrekt programmiert und das Program startet.

Vielen Dank!

Holger

[Joerg W. (joergwolfram)]

Könntest Du probieren, ob es bei Dir auch mit dem Hexfile aus dem Archiv 
geht (direkt in den AVR programmieren)?

Jörg

[Joachim B. (jar)]

Joerg W. schrieb:
> Eventuell bekommt der PI Timing-Probleme mit der libftdi, dann müsste
> man sich überlegen, die Bitrate von derzeit 1,25MBps für diesen Fall auf
> z.B. 500KBps zu senken

ich habe meine Arduinos (AVR1284p muss ich noch) im Bootloder nach 
Optiboot mit 115k wieder auf 57k6 gesenkt. Damit hat der PI auch keine 
Probleme.

[Holger M. (nezaya)]

Hallo Jörg,

> Könntest Du probieren, ob es bei Dir auch mit dem Hexfile aus dem Archiv
> geht (direkt in den AVR programmieren)?

Ich hatte direkt das main-usb.hex aus dem Archiv genommen um via avrdude 
yu programmieren und nicht das von dir nochmal extra hochgeladene 
uprog-usb.hex. Beantwortet das die Frage?

Noch eine Frage zum Bereitstellen der Programmierspannung via PA4 bis 
PA7. Im Assembler Code (label vcc_on) habe ich dazu die Teile gefunden, 
die das ein- und ausschalten. (Dort wird auch noch irgendwie PD3 
benutzt?) Aber kann ich das Ein- und Ausschalten vom PC aus 
kontrollieren? Bisher habe ich es nämlich nicht geschafft beim 
Programmieren des HCS08 die Spannung vom uprog zu beziehen.

Holger

[Joerg W. (joergwolfram)]

Die Entscheidung, ob das Device über den Programmer versorgt wird ist 
abhängig von der gemessenen Spannung an V-Ext. Liegt diese unter 0,5 
Volt, sollte der Programmer die Versorgung übernehmen. Die Schwelle 
ließe sich sicher auch auf 2..3 Volt erhöhen.
PD3 ist optional dazu gedacht, die Spannung über einen über einen 
P-Kanal FET zu schalten, wird aber in der Schaltung nicht benutzt.

Jörg

[Joerg W. (joergwolfram)]

Letztens ist bei mir auch das Update schiefgegangen, hier werde ich evtl 
noch Prüfsummen oder ein Verify einbauen.


Wenn jemand ein Layout macht, bitte PD4 offen lassen. In der nächsten 
Version will ich die beiden Varianten (USB und Bluetooth) codemäßig 
zusammenfassen und die Unterscheidung über PD4 machen.
Bei der Gelegenheit würde ich auch die Schwelle zur externen 
Spannungserhöhung anpassen, evtl auf 1,5V erhöhen.


Jörg

[Renate (Gast)]

Gibt es denn Neuigkeiten beim PCB, z.B. Gerber-Datei?

[Holger M. (nezaya)]

Hier gibt es doch schon ein Layout, inklusive Gerber Datei.

Holger M. schrieb:
> Mit Unterstützung meines Arbeitgebers, der Primes GmbH (www.primes.de),
> folgt hier ein erstes Layout (Schaltplan, BOM und Gerber) und ein
> einfaches Gehäuse (STEP) zum 3D Drucken für den uprog2. Das alles in der
> ZIP Datei im Anhang.

Joerg W. schrieb:
> Wenn jemand ein Layout macht, bitte PD4 offen lassen.

Sogar PD4 ist schon offen.

[Jens (Gast)]

Wird es eine Erweiterung für die neuen Atmegas mit UPDI geben?

[Joerg W. (joergwolfram)]

> Wird es eine Erweiterung für die neuen Atmegas mit UPDI geben?

Im Moment wohl eher nicht. Das hängt damit zusammen, dass ich mir dafür 
extra ein Board oder Device kaufen müsste, welches nachher nur rumliegt. 
Und so etwas widerstrebt mir halt.

Aber das muss nicht heißen, dass es nie kommt...

Jörg

[Joerg W. (joergwolfram)]

Ich hab mich mal damit beschäftigt, allzu schwierig wird es nicht sein. 
Den Widerstand kann man ja in das Adapterkabel verfrachten. Für die 12V 
bei den Tinys braucht es dann noch eine Diode von Pin 9 (VPP) und eine 
Schutzmaßnahme am Datenpin.

Ein ATMEGA4809 Board kann ich jetzt leihweise bekommen, also sollte sich 
im Laufe des Sommers was tun...

Ansonsten steht als Nächstes wohl noch der ESP32 an, denn nicht immer 
will man einen USB-Seriell-Wandler mit auf dem Board haben.

Jörg

[usuru (Gast)]

Joerg W. schrieb:
> denn nicht immer
> will man einen USB-Seriell-Wandler mit auf dem Board haben.

Den kann man doch sehr gut separat haben, mache ich so. Und das ESP-Tool 
ist in Python geschrieben, läuft also auf allen OS.

[Joerg W. (joergwolfram)]

Ich denke eher daran, den SPI-Flash in den Modulen direkt mit dem 
Programmer zu beschreiben. Die dazugehörigen Pins kann man ja praktisch 
sowieso nicht als I/O benutzen. Die eigentliche Aufgabe wird also nur 
sein, das Image zu erstellen, Routinen für SPI-Flashes gibt es ja schon 
im Programmer.
Außerdem wären dann RXD0 und TXD0 frei für andere Dinge.

Jörg

[usuru (Gast)]

Joerg W. schrieb:
> Außerdem wären dann RXD0 und TXD0 frei für andere Dinge.

Das wäre sehr gut !

[Holger M. (nezaya)]

Ist hätte ich noch zwei Verbesserungsvorschläge oder Wünsche für eine 
mögliche nächste Version.

Joerg W. schrieb:
> Die Entscheidung, ob das Device über den Programmer versorgt wird ist
> abhängig von der gemessenen Spannung an V-Ext. Liegt diese unter 0,5
> Volt, sollte der Programmer die Versorgung übernehmen. Die Schwelle
> ließe sich sicher auch auf 2..3 Volt erhöhen.
> PD3 ist optional dazu gedacht, die Spannung über einen über einen
> P-Kanal FET zu schalten, wird aber in der Schaltung nicht benutzt.

Wäre es möglich einen Kommandozeilenparameter einzubauen, der die 
Spannungsversorgung erzwingen kann?

Joerg W. schrieb:
>> Korrektur: Es war ein zweites FTDI Device angeschlossen und das scheint
>> uprog2 zu verwirren.
> Das mit dem 2.FTDI ist mir auch schon passiert, bei der Entwicklung von
> meinem PDP11-Emulator war das zeitweilig arg nervig, weil ich zum Testen
> immer einen seriellen Port gebraucht habe.

Gäbe es da eine Chance für einen Workaround? Leider wird an dem System 
an dem der uprog2 hängt auch immer eine weitere FTDI basierte Hardware 
angeschlossen.
Könnte man den USB Device- und/oder Manufacturer-Namen im uprog2 FTDI 
eventuell entsprechend setzen und dann nur gezielt auf den uprog2 
verbinden, ohne sich auf die nicht eindeutige vid und pid zu verlassen? 
Wenn ich die Libusb da noch richtig kenne, dann muss man dazu wohl dazu 
leider alle passende Devices durchgehen und z.B. 
libusb_get_string_descriptor() aufrufen. Wie das bei der bisher 
verwendeten libftdi aussieht musste ich rausfinden.
Die passenden Descriptoren könnte man mit FTDI FT_PROG (Windows only) 
[1,2] einstellen. Unter Linux habe ich für das Einstellen noch keine 
wirkliche Lösung gefunden. ftx-prog [3] scheint nahe dran zu sein, aber 
nicht für den verwendeten FT232 Baustein, wobei ich das jetzt noch nicht 
ausprobiert habe.
Der Code zum Verbinden liegt wohl in modules/daemon.c um Zeile 150. 
Vielleicht kann ich da auch einen Patch beisteuern.

[1] https://www.ftdichip.com/Support/Utilities.htm#FT_PROG
[2] 
https://www.ftdichip.com/Support/Documents/AppNotes/AN_124_User_Guide_For_FT_PROG.pdf
[3] https://github.com/richardeoin/ftx-prog

Holger

[Holger M. (nezaya)]

Zum zweiten Verbesserungsvorschlag wird auch direkt geliefert:
Ein Beispiel zum Finden des Gerätenamens findet sich in den Sourcen zur 
Libftdi [1,2]. Das habe ich hier um die Anzeige der Seriennummer 
erweitert.

/* find_all.c
    
       Example for ftdi_usb_find_all()
    
       This program is distributed under the GPL, version 2
    */
    
   #include <stdio.h>
   #include <stdlib.h>
   #include <ftdi.h>
   
   int main(void)
   {
       int ret, i;
       struct ftdi_context *ftdi;
       struct ftdi_device_list *devlist, *curdev;
       char manufacturer[128], description[128], serialnumber[128];

       int retval = EXIT_SUCCESS;
   
       if ((ftdi = ftdi_new()) == 0)
       {
           fprintf(stderr, "ftdi_new failed\n");
           return EXIT_FAILURE;
       }
   
       if ((ret = ftdi_usb_find_all(ftdi, &devlist, 0, 0)) < 0)
       {
           fprintf(stderr, "ftdi_usb_find_all failed: %d (%s)\n", ret, ftdi_get_error_string(ftdi));
           retval =  EXIT_FAILURE;
           goto do_deinit;
       }
   
       printf("Number of FTDI devices found: %d\n", ret);
   
       i = 0;
       for (curdev = devlist; curdev != NULL; i++)
       {
           printf("Checking device: %d\n", i);
           if ((ret = ftdi_usb_get_strings(ftdi, curdev->dev, manufacturer, 128, description, 128, serialnumber, 128)) < 0)

           {
               fprintf(stderr, "ftdi_usb_get_strings failed: %d (%s)\n", ret, ftdi_get_error_string(ftdi));
               retval = EXIT_FAILURE;
               goto done;
           }
           printf("Manufacturer: %s, Description: %s, Serial: %s\n\n", manufacturer, description, serialnumber);
           curdev = curdev->next;
       }
   done:
       ftdi_list_free(&devlist);
   do_deinit:
       ftdi_free(ftdi);
   
       return retval;
   }

Die Ausgabe sieht beispielsweise so aus:

Number of FTDI devices found: 1
Checking device: 0
Manufacturer: FTDI, Description: FT232R USB UART, Serial: A9IXHV77

Die Description könnte man jetzt mit dem im vorherigen Post genannten 
FT_PROG z.B. auf uprog2 ändern und den String entsprechend vergleichen.

Ein so gefundenes Device dev könnte man dann statt mit

int ftdi_usb_open (struct ftdi_context *ftdi, int vendor, int product)

mit folgender Funktion öffnen [3].

int ftdi_usb_open_dev (struct ftdi_context *ftdi, libusb_device *dev)

Alternativ gibt es in der Liste der Funktionen zum Öffnen auch gleich 
welche, die eventuell direkt genutzt werden können [3].

int ftdi_usb_open_desc (struct ftdi_context *ftdi, int vendor, int product, const char *description, const char *serial)
int ftdi_usb_open_desc_index (struct ftdi_context *ftdi, int vendor, int product, const char *description, const char *serial, unsigned int index)
int ftdi_usb_open_bus_addr (struct ftdi_context *ftdi, uint8_t bus, uint8_t addr)
int ftdi_usb_open_string (struct ftdi_context *ftdi, const char *description)

Man müsste sich dann nur noch auf einen Device-Namen für den uprog 
einigen, oder diesen per define oder Kommandozeilenparameter 
konfigurierbar machen.

Alternativ könnte man auch die Seriennummer des FTDI Device auf der 
Kommandozeile übergeben. Dann muss sogar überhaupt kein Setting 
verändert werden.

Soll ich einen Patch für main.c und daemon.c liefern?

[1] 
http://developer.intra2net.com/git/?p=libftdi;a=blob;f=examples/find_all.c
[2] 
http://developer.intra2net.com/git/?p=libftdi;a=blob;f=examples/find_all.c;h=4a70650004284347163ce4840443dc125135772d;hb=80101c71c06f7c017c5438a08f51fdf17768f8ca
[3] 
https://www.intra2net.com/en/developer/libftdi/documentation/group__libftdi.html

[Joerg W. (joergwolfram)]

Mir würde es wesentlich mehr zusagen, wenn der Name auf UPROG2 
festgelegt wird und, wenn möglich, das serielle Device vom System gar 
nicht mehr erkannt wird. Der libftdi dürfte das ja nichts ausmachen.
Dann sollte ein USB-Seriell Wandler immer als /dev/ttyUSB0 erscheinen, 
egal was zuerst angesteckt wird.

Bei der Spannungsversorgung aus dem Pogrammer habe ich folgenden 
Vorschlag:

ohne Option = keine Versorgung
3V = 3,3V Versorgung
5V = 5V Versorgung

Jörg

[Holger M. (nezaya)]

Das klingt beides super.

Bezüglich der Strings ist der usbserial Treiber im Linux da meines 
Wissens nach sehr flexibel. Er geht (standardmäßig) ebenfalls nur nach 
den VID und PID und ignoriert die Strings einfach. Dann würde also beim 
UPROG2 als Namen ein trotzdem ttyUSB erzeugt. Ich kann aber nochmal 
nachschauen.

Ganz ideal wäre natürlich eine eigene VID:PID.

Ich habe jetzt mal testweise in der daemon.c sowohl USB_VID, USB_PID, 
als auch USB_MANUFACTURER, USB_DESCRIPTOR und USB_SERIALNUMBER als 
define festlegbar gemacht. Dann kann man später noch überlegen, welches 
davon man eventuell als Kommandozeilenparameter rausziehen will.

Dummerweise fehlt mir jetzt gerade das uprog2 Device, so dass ich nicht 
wirklich testen kann. Sonst könnte ich direkt den Patch dazu liefern.

Und noch Vorschlag:
Ein Kommandozeilenparameter, der nur den Daemon startet um Daemon 
separat, zum Beispiel beim Systemstart oder als andere Nutzer, starten 
zu können.

[M. (Gast)]

Schon mal was von openocd gehört? Ich verwende das hauptsächlich zum 
Flashen von STMicro MCUs.

[Holger M. (nezaya)]

> Schon mal was von openocd gehört? Ich verwende das hauptsächlich zum
> Flashen von STMicro MCUs.

Gut gemeinter Hinweis.

Wenn man mit den von OpenOCD unterstützen Controllern arbeitet, würde 
ich auch immer OpenOCD empfehlen. Auch zum programmieren, auch wenn das 
nicht die Hauptaufgabe von OpenOCD ist.
uprog2 unterstützt als Programmer aber diverse Controller die OpenOCD 
nicht kennt und für die es auch wohl nicht wirklich mehr Sinn mach das 
in OpenOCD unterzubringen.

Und damit dürfte dieser kleine Offtopic Ausflug auch beendet sein.

[Holger M. (nezaya)]

Joerg W. schrieb:
>> @Joerg W.: Gäbe es Einwände den Code so wie er ist in ein GitHub Projekt
>> zu importieren?
>
> Eigentlich nicht.

Ich habe das mal gemacht und auch gleich noch etwas Doku hinzugefügt 
[1].

Im Branch usb_id gibt es einen modifizierten "Daemon" [2],
der aber erstmal nichts anderes macht, als die oben erwähnten USB Infos 
auszuspucken.

Number of FTDI devices found: 1
Checking device: 0
Manufacturer: FTDI, Description: FT232R USB UART, Serial: A9IXHV77

Am Ende der README.md [3] folgt die Info wie man die Strings umstellen 
kann. Auch unter Linux.

Das Ergebnis ist dann beispielsweise folgendes.

Number of FTDI devices found: 1
Checking device: 0
Manufacturer: 5inf, Description: USBPROG2, Serial: 0815

Ich denke damit wären alle Teile zusammen um die Erkennung des korrekten 
uprog2 Devices in ermöglichen.

Nur das Assemblieren des ARV Binaries auf Linux klappt noch nicht, da 
der avra Assmbler den ATmega644 nicht von Haus aus kennt. Das ist mir 
aber derzeit erstmal nicht so wichtig.

[1] https://github.com/5inf/uprog2
[2] https://github.com/5inf/uprog2/tree/usb_id/source/TEST
[3] https://github.com/5inf/uprog2/blob/master/README.md

[Joerg W. (joergwolfram)]

Ich habe am WE ein paar Versuche gemacht, mit ftdi_eeprom kann man ja 
auch leicht die PID ändern. Ich dachte bis jetzt, dass man dafür Windows 
braucht, und das war für mich nicht akzeptabel. Mit einer PID 6661 wird 
der Programmer auch nicht mehr als serielles Device erkannt, was auch 
sehr praktisch ist, weil dann mein USB-Seriell-Wandler immer unter 
/dev/ttyUSB0 erreichbar ist. Und ich muss in der daemon.c nur die neue 
PID ändern und eine neue udev-Rule schreiben.

Das lässt sich sicherlich noch in ein kleines Install-Script verpacken, 
welches man einmalig als root aufrufen muss.

Was ich noch nicht ganz verstanden habe, welchen Nutzen hat es, den 
Daemon als anderer Nutzer zu starten? Sobald der Programmer abgezogen 
wird, beendet sich der Daemon nach kurzer Zeit. Und mit passender 
udev-Rule braucht man ja auch nicht root zu sein.

Jörg

[Holger M. (nezaya)]

uprog2 ist in dem Fall Teil einer (teil-)automatisierten Test und 
Programmierstation.

Der Wunsch den Daemon separat starten zu können rührt daher, dass ich 
ihn beim Systemstart mit starten möchte um dort gleich zumindest zu 
prüfen, ob der Programmer angeschlossen ist. Der Rest des Testsystems 
läuft dann aber mit ggf. anderen Rechten oder auch mit unterschiedlichen 
Nutzern. Ich könnte natürlich auch starten, killen und dann wieder als 
anderer Nutzer starten. Bisher funktioniert aber das einmalige Starten 
des Daemons, z.B. als Benutzer A und dann der Zugriff als Benutzer B 
ziemlich gut. Außer natürlich, das ich erstmal einen Programmierbefehl 
absetzen muss, der dann mangels angeschlossenem Target fehlschlägt.

Wie sieht denn deine udev Regel aus?

Holger

[Joerg W. (joergwolfram)]

Hallo Holger,

Du kannst auch den Dämon starten, indem Du irgendein gültiges Device und 
-help als Kommando angibst. In der kommenden Version werde ich auch nur 
dann 0 zurückgeben, wenn alles OK war (die aktuelle Version gibt immer 0 
zurück).

Meine udev-Regeln sehen momentan so aus:

ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="0666"
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6661", MODE="0666"

Jörg

[Joerg W. (joergwolfram)]

Es gibt jetzt ein Update auf Version 1.35 bei dem die meisten Sachen 
schon eingeflossen sind. Um die PID zu ändern, habe ich ein kleines 
Script geschrieben und auch eins, um die dazu passende UDEV-Regel zu 
installieren.
Außerdem sind jetzt die ersten AVR0 mit UPDI dabei, wobei ich den 
12V-Puls  bei den ATTiny mangels Devices noch nicht testen konnte. 
Außerdem ein paar Bugfixes u.a. bei den RH850 MCs.

http://www.jcwolfram.de/projekte/uprog2/main.php

Jörg

[Joerg W. (joergwolfram)]

Es gibt wieder ein neues Update auf Version 1.36

Als "neues" Device ist der AT89S8252 hinzugekommen, Außerdem habe ich 
einen Fehler bei den XC9500XL gefixt.

Bei den RH850 funktioniert jetzt auch Bootstrapping (direkt Code im RAM 
ausführen) und die Liste der unterstützten Devices ist wieder ein Stück 
größer geworden.

http://www.jcwolfram.de/projekte/uprog2/main.php

Jörg

[Holger M. (nezaya)]

Hallo Jörg,

ich habe gerade auf die Version 1.36 aktualisiert und bekomme jetzt beim 
Programmieren des MC9S08DN60 immer ERROR CODE 9F oder gar keine Antwort 
(uprog2 hängt unbegrenzt oder zumindest sehr lange).

sudo uprog2 MC9S08DN60 -t8

>> USB programmer is active.

*** MC9S08DN60 can be programmed with: (1=VSS  2=VDD  3=RESET  4=BKGD) ***

ERROR CODE 9F

Errorcode: 159
FATAL: CONNECTION TO PROGRAMMER LOST!
   <<< PLEASE RESET PROGRAMMER >>>

Errorcode 9F habe ich im Code im Bezug auf einen Timeout gefunden. Sonst 
bin ich mit dem debuggen aber noch nicht viel weiter gekommen.

Der Fehler tritt bei beiden getesteten Programmern auf.
Die vorher eingesetzte Version 1.33 lief im gleichen Setup stabil.

Der verwendete Code ist hier zu finden: https://github.com/5inf/uprog2

Es ist die 1.36, mit einer zusätzlichen Ausgabe des Errorcode in main.c 
(mitlerweile eigentlich obsolet, da bereits implementiert) und einer 
angepassten USB ID in daemon.c. Gebaut und verwendet auf zwei 
RaspberryPi 3 B+ mit einem aktuellen Debian 9 bzw. einem aktuellen 
Debian 10 drauf.
Die Programmer Hardware ist die hier von mir bereits vorgestellte.

Hast du eine Idee woran das liegen kann?

Nachtrag: Wenn ich mit Version 1.36 versuche die beiden Programmer 
gegenseitig selbst zu programmieren, mit

sudo uprog2 ATMEGA644PA -empmvm main-usb.hex

 dann bekomme ich

>> USB programmer is active.

*** ATMEGA644PA can be programmed with: (1=VSS  2=VDD  3=RST  4=SCK  5=MISO  6=MOSI) ***

SYS-Ver =  1.5
PRG-Ver =  0014
V-Ext   =  3.7V
V-PROG  =  5.8V

und dann geht es ebenfalls nicht mehr weiter. Das SYS-Ver update ist 
aber einmal erfolgreich durchgelaufen.

Eventuell ist es das selbe wie wir weiter oben schon mal hatten.
Beitrag "Re: "Universalprogrammer" für Linux"

[Joerg W. (joergwolfram)]

Versuche mal, Zeile 410:

  if(errcode == 0) prg_comm(0x0f,100,100,0,0,0,0,0,0);

auszukommentieren. Das scheint die Ursache dafür zu sein, dass manchmal 
nach dem Update der Programmer "hängt".

Evtl. kann man auch das Update auch nochmal von Hand anstossen:

uprog2 UPDATE -us main.hex

Parallel dazu werde ich in den nächsten Tagen versuchen, einen HCS08 zu 
programmieren.

Jörg

[Holger M. (nezaya)]

Hallo Jörg,

danke für die Rückmeldung und die Vorschläge. Noch läuft es leider 
nicht.

Ich habe den update Befehl

uprog2 UPDATE -us main.hex

ausprobiert. Selbes Ergebnis.

uprog2 daemon is not active, starting daemon and searching for programmer...

>> USB programmer is active.

ERROR CODE 9F

Ich habe aus main.c in Zeile 410 den Befehl

if(errcode == 0) prg_comm(0x0f,100,100,0,0,0,0,0,0);

entfernt und einen weiteren Programmer, noch mit der System-Version 0012 
(aus Version 1.33) genommen und angeschlossen und anschließend

uprog2 UPDATE -us main.hex

ausgeführt.

Danach auch auf dem neuen Programmer das gleiche Bild.

Ein Abstecken und wieder anstecken mit dem Update Befehl, oder 
irgendeinem anderen Befehl , z.B.

sudo uprog2 ATMEGA644PA -empmvm main-usb.hex

 erlaubt zumindest bis

uprog2 daemon is not active, starting daemon and searching for programmer...

>> USB programmer is active.

SYS-Ver =  1.5
PRG-Ver =  0014
V-Ext   =  2.8V
V-PROG  =  2.1V

oder

>> USB programmer is active.

*** ATMEGA644PA can be programmed with: (1=VSS  2=VDD  3=RST  4=SCK  5=MISO  6=MOSI) ***

zu kommen. Aber auch dann erfolgt wieder irgendwann der Timeout

ERROR CODE 9F

.

Wenn ich einen auf 0014 aktualisierten Programmer mit einer Version 1.33 
anspreche kann der einen Downgrade auf Version 0012 durchführen.

Danach passiert aber auch nichts mehr. Selber Timeout. Vielleicht liegt 
das an der Ich versuche noch mal die System Version via externem 
Programmer aufzuspielen und dann zu testen. Das war hier 
(Beitrag "Re: "Universalprogrammer" für Linux") ja schon mal 
hilfreich.

[Holger M. (nezaya)]

Ein manuelles Aufspielen der jeweiligen System Version durch einen 
externen Programmer (JTAG ICE) hilft auch nur bedingt.

Ich bin im Moment etwas ratlos.

Ich habe zwei exakt gleiche RAspberryPi, die mit dem gleichen Image 
booten:
RaspberryPi 0 und RaspberryPi 2.
Ich habe zwei Programmer, beide von extern (AVR Studio) mit dem main.hex 
Image 0014 bespielt: Programmer 2  und Programmer 0.

Ich teste mittels

 sudo uprog2 MC9S08DN60 -t8

, ohne angeschlossenes Target.

Programmer 2 funktioniert an Pi 2. Ausgabe:

>> USB programmer is active.

*** MC9S08DN60 can be programmed with: (1=VSS  2=VDD  3=RESET  4=BKGD) ***

SYS-Ver =  1.6
PRG-Ver =  0014
V-Ext   =  2.8V
V-PROG  =  1.9V
## Action: main flash erase
## Action: main flash program using /fw/Cube_4-1.s19
## Action: main flash verify using /fw/Cube_4-1.s19
## Action: trimming ICG to 8Mhz


ERROR 31 (49):  (No SYNC answer)                                                
Failure

Der Programmierprozess kann also gestartet werden und es wird auch 
koorekterweise kein Target gefunden. In dieser Konfiguraition kann ich 
auch tatsächlich programmieren. Nicht nur HCS08, sondern auch AVR und 
weitere Controller.

Programmer 0 funktioniert nicht an Pi 2. Ausgabe:

uprog2 daemon is not active, starting daemon and searching for programmer...

>> USB programmer is active.

*** MC9S08DN60 can be programmed with: (1=VSS  2=VDD  3=RESET  4=BKGD) ***

ERROR CODE 9F

FATAL: CONNECTION TO PROGRAMMER LOST!
   <<< PLEASE RESET PROGRAMMER >>>
Failure

Programmer 2 funktioniert nicht an Pi 0.

Programmer 0 funktioniert nicht an Pi 0.

Die Hardware und auch die Softwarestände sind gleich (gleiche Images).

Das Verhalten bleibt gleich, wenn in main.c die Zeile 410 enthalten ist 
oder nicht. Das Verhalten ist so beliebig oft wiederholbar, ob mit oder 
ohne Reboot der RaspberryPis.

Mit der vorherigen Version 1.33 funktionieren alle Kombinationen.

Es könnte also in der Tat irgendein Timing Problem sein.

Am PC unter Debian, allerdings in einer VM, ist das Problem das gleiche.

[Joerg W. (joergwolfram)]

Ich habe jetzt meine aktuelle Version an 3 verschiedenen Laptops (64 
Bit) und einer VM (32 Bit) ausprobiert und dabei keine Probleme 
feststellen können. Ich habe mal eine Preview angehängt.

Hattest Du bei der V1.33 auch schon die neue VID/PID programmiert? Wenn 
nein, könntest Du den FTDI wieder auf die originalen Daten zurückstellen 
und damit testen.

Jörg

[Joerg W. (joergwolfram)]

Es gibt ein neues Update auf Version 1.37

Dabei sind wieder ein paar neue Devices/Familien dazugekommen:

-NXP/Freescale S12Z
-NXP/Freescale MPC574x
-STM SPC584xx
-Silabs EFM32/EFR32

Weggefallen ist das 32-Bit Binary, falle es doch jemand benötigt, dann 
bitte bei mir melden.

http://www.jcwolfram.de/projekte/uprog2/main.php

Jörg

[Joerg W. (joergwolfram)]

Ich habe gestern festgestellt, dass es mit der aktuellen Version 
Probleme bei den S12X Controllern gibt. Das kommt daher, dass ich für 
die S12Z das BDM-Timing anpassen musste und die Frequenzmessung für die 
anderen Devices mit BDM nun falsche Werte liefert.

Ich werde das so schnell wie möglich korrigieren. Bis dahin ist es 
sinnvoller, bei Version 1.36 zu bleiben (sofern das ausser mir überhaupt 
noch jemand nutzt).

Jörg

[Stephan S. (uxdx)]

Joerg W. schrieb:
> sofern das ausser mir überhaupt noch jemand nutzt).

Bin nach wie vor dabei

Gruss S.

[Holger M. (nezaya)]

Ich nutze den Programmer auch noch.
Ich pflege die neuen Versionen auch immer hier nach: 
https://github.com/5inf/uprog2

Allerdings habe ich immer noch das Problem das die Versionen nach 1.33 
nicht mehr reproduzierbar stabil laufen. Ich kam nach dem letzten Post 
im März aber noch nicht dazu das wieder priorisiert anzugehen. Die 
RaspberryPis mit den 1.33 laufen zum Glück weiter. Ich hoffe das die 
nächsten Wochen nochmal angehen zu können.

Bestünde Interesse für die uprog2 Hardware eine eigene, reservierte USB 
ID zu haben? Dann könnten wir uns eventuelle mal per PN oder Mail 
austauschen.

[Holger M. (nezaya)]

Im Makefile in source/Host ist noch der Verweis auf das 64 bit Binary 
drin.

install:        bin
        cp -f uprog2-64 /usr/local/bin/uprog2

Korrekt müsste es aber folgendes sein, da das Binary nur noch uprog2 
heißt.

install:        bin
        cp -f uprog2 /usr/local/bin/uprog2

[Joerg W. (joergwolfram)]

Danke für den Hinweis. Bei mir fällt das gar nicht auf, da ich das make 
von einem Build-Script aufrufe und das kopieren des Binarys von Script 
gemacht wird. Das werde ich auf jeden Fall korrigieren.

Neben den S12X sind in der aktuellen Version auch die S08 Controller 
betroffen, ich habe schon eine neue Version, will sie aber 
vorsichtshalber noch mit verschiedenen Boards testen.

Für eine eigene USB-ID sehe ich eigentlich keinen Bedarf, da ich das 
Projekt nicht kommerziell vertreibe und die aktuelle genutzte PID von 
keinem Treiber "In Beschlag" genommen wird. Der Zweck von der anderen 
PID war ja nur, dass der Programmer nicht mehr als serielles Device 
erscheint.

Jörg

[Joerg W. (joergwolfram)]

Ich habe Version 1.38 online gestellt, damit sollte das BDM-Problem 
behoben sein. Da der S12Z beim Start nur mit 1MHz läuft, waren die 
bisherigen Routinen zu schnell und ich hatte die Messung der 
BDM-Frequenz um den Faktor 3 verlangsamt. Dadurch wurde bei anderen 
BDM-Devices die Frequenz falsch ermittelt und um den Faktor 3 zu hoch. 
Die neue Version nutzt nun getrennte Routinen für S12Z und die anderen 
Devices mit BDM.

Als nächstes Ziel habe ich Unterstützung für 1-Wire EEPROMs geplant und 
Verbesserungen bei den Timeouts, soweit das mit vertretbarem Aufwand 
möglich ist.

Jörg

[Joerg W. (joergwolfram)]

Es gibt wieder eine neue Version (1.39). Neben DS28E07 sind auch die 
STM32F7xx und weitere R8C Typen dazugekommen. Für den RL78 ist eine 
Funktion dazugekommen, das Daten-Flash zu dumpen. Normalerweise geht das 
nicht, da der Bootloader kein Readout unterstützt, aber manchmal braucht 
man eine Möglichkeit, zu Debuggingzwecken die Daten zu kontrollieren, 
die der Controller selbst in das DataFlash schreibt. Dabei werden 
allerdings die ersten 2K im Code-Flash überschrieben, aber das war für 
meine Zwecke das kleinere Problem, da ich das Hauptprogramm danach 
einfach wieder drüber flashen konnte.

Neu hinzugekommen sind auch rudimentäre Debugging-Funktion für 
Controller mit Cortex-M Kernen und SWD. Als Funktionen sind derzeit 
implementiert:

- Debuggen von Programmen im Flash oder RAM
- Einzelschritt
- Breakpoint
- Continue und Goto
- Register lesen und schreiben
- Speicher/IO lesen und schreiben

Eventuell ließe sich das auch später in einen Debugger wie OpenOCD 
integrieren um auch Hochsprachenprogramme zu debuggen.

http://www.jcwolfram.de/projekte/uprog2/main.php

Jörg

@Holger: Ich hatte Dir eine PN geschickt, evtl ist sie nicht angekommen. 
Du kannst mich auch direkt per Mail kontaktieren.

[Joerg W. (joergwolfram)]

Es gibt wieder eine neue Version (1.40). Erstmals habe ich auch eine 
Version auf dem Raspberry Pi compiliert und getestet, allerdings noch 
auf einem alten Modell (PI B).

Daneben werden jetzt die ATMega über JTAG und die ATTiny 1xxx 
unterstützt. Debugging ist nun auch für die HCS08 implementiert, für die 
ATMega über JTAG habe ich damit angefangen, bin aber zu keinem 
vernünftigen Ergebnis gekommen und werde das wohl auch nicht mehr 
weiterverfolgen. Da fehlt halt leider die Doku...

Ansonsten ein paar neue Funktionen für die S32K und RL78 Familien, 
Überarbeitung der Typenlisten und ein paar kleinere Bugfixes.

Download wie üblich über meine Webseite:

http://www.jcwolfram.de/projekte/uprog2/main.php

oder

https://joergwolfram.noip.me/hp/projekte/uprog2/main.php

Jörg

[Joerg W. (joergwolfram)]

In der aktuellen Version (1.41) gibt es hauptsächlich kleine 
Ergänzungen, Optimierungen und Bugfixes. Insbesondere sollte die 
Update-Funktion nun (wieder) richtig funktionieren. Ursache war ein 
Fehler im Script, welches das Hexfile in ein C-Include umwandelt.
Außerdem gibt es jetzt eine Option (-vp), mit der auch FTDI232 mit 
Original-PID funktionieren.

Download wie üblich über meine Webseite:

http://www.jcwolfram.de/projekte/uprog2/main.php

oder

https://joergwolfram.noip.me/hp/projekte/uprog2/main.php

Jörg

[Joerg W. (joergwolfram)]

Hallo,

seit dem letzten WE gibt es nach längerer Zeit wieder eine neue Version 
(1.42)

Neben ein paar nezuen Devices (Remesas RA6, Infineon TL986x) sowie 
diversen Bugfixes gibt es noch ein paar Änderungen am System insgesamt:

Zum Ersten wird bei angeschlossenem USB-Programmer der Dämon nicht mehr 
gestartet, sondern direkt kommuniziert. Ursache war eigentlich
ein USB-Kabel mit Wackelkontakt gewesen, hin und wieder "verschluckte" 
sich der Dämon und musste manuell gekillt werden.

Außerdem lässt sich das Handshake für den USB per Kommando abschalten, 
da ich das für Android mit OTG Adapter nicht richtig konfigurieren 
konnte.
Die Android-App liegt allerdings erstmal auf Eis, da ich bis jetzt einen 
einen vernünftigen Zugriff auf den Download-Ordner ohne Root-Rechte 
nicht hinbekommen habe.

Bereits in Vorbereitung (im Host-Programm schon integriert) ist ein 
BT-Parallel-Programmer für Flash-Bausteine auf Basis eines STM32F411 
Discovery,
hier müsste ich noch Dokumentation und Quellcode nachliefern, wofür aber 
momentan ein bisschen die Zeit fehlt. Sollte Interesse daran bestehen,
bitte einfach hier ins Forum mit reinschreiben.

Jörg

[Holger M. (nezaya)]

Kurzer Hinweis, dass für 1.42 und ggf. auch schon davor, die Fuses nicht 
wie auf der Webseite [https://www.jcwolfram.de/projekte/uprog2/main.php] 
derzeit beschrieben als

> Zuerst sollten die Fuses prorammiert werden. Für den Mega644 ist folgende 
Einstellung vorgesehen (Änderung ab Version 1.32):
>LOW FUSE: 0xe6
>HIGH FUSE: 0xd0
>EXT FUSE: 0xff

gesetzt werden müssen, sondern als

>LOW FUSE: 0xe6
>HIGH FUSE: 0xd4
>EXT FUSE: 0xff

Da ich da gerade schon wieder drüber gestolpert bin, steht das jetzt 
auch in der Readme auf https://github.com/5inf/uprog2.

[Holger M. (nezaya)]

Noch drei Ergänzungen zu meinem vorherigen Eintrag:

1. Im Download-Archiv 
[https://www.jcwolfram.de/downloads/files/uprog2/uprog2-v1.42-release.tar.bz2] 
für die Version 1.42 ist im Verzeichnis binary/PI/ noch ein Binary, das 
sich mit 1.41 meldet. Im Git Repo habe ich die Binaries inzwischen 
komplett entfernt.

2. Die Beschreibung zum Bauen von uprog2 (speziell Version 1.42) unter 
https://github.com/5inf/uprog2 ist jetzt nochmal geprüft und 
vollständig.

3. Im hier weiter oben 
[Beitrag "Re: "Universalprogrammer" für Linux"] bereits 
angehängten und auch im GitHub Repo unter /hw/pcb veröffentlichten 
Schaltplan und Platinenlayout in Revision 0.0.0 gibt es noch ein paar 
Fehler im Bereich der Spannungsversorgung und der FTDI Baustein ist 
falsch spezifiziert. Jörg hat geholfen das aufzudecken. Danke dafür!
Die Programmer funktionieren so zwar, aber ich werde die Änderungen 
trotzdem nachziehen und demnächst auch die neue Revision auf GitHub 
bereitstellen. Wie das bisherige Layout auch kann man die Platinen dann 
wahrscheinlich auch wieder unter https://oshpark.com/profiles/5inf 
bestellen.

[Joerg W. (joergwolfram)]

Mit der PI Version hast Du recht, da habe ich im Build-Script den Pfad 
nicht aktualisiert. Da ich die PI-Version auf dem PI kompiliere, 
synchronisiere ich das über meine Nextcloud. Beim Build (was natürlich 
in einem anderen Verzeichnis stattfindet) wird dann das Binary mit in 
das Archiv gepackt. Und hier hatte ich halt den Fehler, dass die 
PI-Version nicht mit hochgezählt wurde.

Bei der demnächst erscheinenden Version 1.43 werde ich das (hoffentlich) 
beheben.

Jörg

[Stefan F. (Gast)]

Das Problem aller Universalprogrammer ist, dass andauernd eine neue 
Schnittstelle heraus kommt die er noch nicht kann. Ich erinnere mich an 
einen Hersteller, der auf austauschbare Adaptermodule setzte. Aber schon 
nach wenigern Jahren konnte man keine Adapter mehr kaufen.

[Joerg W. (joergwolfram)]

Das Problem stellt sich hier nicht so, da das Meiste in Software 
realisiert ist. An (physikalischen) Schnittstellen ist in den letzten 
Jahren eher wenig dazugekommen, dafür wir es "hinter den 
Programmierpins" meiner Meinung nach immer komplexer.

Für meine eigenen Projekte verwende ich oft kleine DIL-Module (s. Bild), 
die ich direkt oder über Verlängerungskabel an den Programmer anstecken 
kann. Mit einer (für alle unterstützten Controller) standardisierten 
Bibliothek und Toolchain reicht dann ein einfaches "make prog", um vom 
Quelltext zu einem funktionsfähigen Device zu kommen.

Für die aktuelle Version bin ich gerade dabei, Logging zu 
implementieren, falls man den Programmer in automatische Abläufe 
einbinden will. Eine weitere Idee ist, die normalerweise ungenutzte 
ISP-Schnittstelle zur Ansteuerung weiterer Komponenten zu benutzen.

Jörg

Edit: Typo

[Joerg W. (joergwolfram)]

Nach knapp einem Jahr gibt es wieder eine neue Version (1.43). Neben 
diversen Bugfixes und Optimierungen sind

- NXP S32K3xx
- TI RF430
- Microchip PIC18FxxQ41/PIC18FxxQ43

als neue Devices dazugekommen. STM32H7 ist zwar aktuell in der Pipeline, 
aber da funktioniert der Bootcode noch nicht richtig. Das Binary für den 
Raspberry Pi sollte jetzt auch in der aktuellen Version mit im Archiv 
sein.

Download wie üblich über meine Webseite:

http://www.jcwolfram.de/projekte/uprog2/main.php

oder

https://joergwolfram.noip.me/hp/projekte/uprog2/main.php

Jörg

[Alex (a_glock)]

Hallo,
Ich habe die letzten Stunden an einer Unterstützung für den HCS08RG60 
gebastelt und wollte mein Ergebnis mal hier teilen (diese Diskussion ist 
das erste was bei einer Suche nach "uprog2 memory maps" erscheint also 
hilft es vielleicht auch als allgemeines Beispiel). Hier kommt 
jedenfalls meine funktionierende Ergänzung in der devices_FSL_HCS08.h 
für den RG60:

 "MC9S08RG60",
 1,
 0x182C,0xE7D4,    //main flash
 0x0000,0x0000,    //ignore lower flash
 0x0000,0x0000,
 0x0000,0x0000,
 0x0056,0x03D6,    //RAM
 0x00000000,    //ID
 0x004a,0x0000,    //TRIM REG
 0x0000,0x0000,
 0x0000,0x0000,
 0x0000,0x0000,

Ich benutze auch nur den großen Flash ab 0x182C deshalb habe ich den 
"lower flash" erstmal ignoriert. Den Code Abschnitt einfach an die 
Header Datei anfügen, neu bauen und das gewünschte Modell kann in der 
LIST gefunden werden.

Alex

[Joerg W. (joergwolfram)]

Danke, ich werde das in die nächste Version mit einfließen lassen. Der 
RAM-Bereich stimmt aber nicht ganz, wenn ich ins Datenblatt schaue. Der 
Eintrag sollte meiner Meinung nach so aussehen

  "MC9S08RG60",
  1,
  0x182C,0xED74,    //main flash
  0x0846,0x0FBA,    //lower flash
  0x0000,0x0000,
  0x0000,0x0000,
  0x0046,0x0800,    //RAM
  0x00000000,    //ID
  0x0000,0x0000,    //NO TRIM REG
  0x0000,0x0000,
  0x0000,0x0000,
  0x0000,0x0000,

Die die Adresse des Trimm-Registers habe ich schon mal auf 0 gesetzt, 
damit in der nächsten Version ein etwaiger Trimm-Befehl (t8/t9/ta) 
ignoriert wird.

Jörg