Probleme mit GALEP 4 [Archiv] - ProgForum.com - Das Elektronik Diskussionsforum

Archiv verlassen und diese Seite im Standarddesign anzeigen : Probleme mit GALEP 4

Import-Script

30.04.2003, 17:30

Hallo, habe da ein Problem mit dem Galep4 und zwar habe ich hier orginale Daten von einer Firma die auf Eproms des Typen 27C040 und 27C020 geprannt werden sollten. Nun wenn ich die Daten brenne funktionieren die Eproms nicht, wenn ich aber ein Orginales Eprom einlese und das dann wieder brenne geht alles 1A. Habe dann das beta Setup von Conitech runtergeholt und jetzt bekomme ich beim Brennen oder Leertest die Meldung "Daten zu gross". Versteh nicht was da falsch läuft, sind jetzt die Daten zu gross für das Eprom oder was und wieso lufen die von der Datei geprannten Eprom´s nicht, beim vergleich mit der Datei findet Galep keine Fehler Gruss MArtin

Import-Script

01.05.2003, 16:10

Kann sein, dass Du in eine ähnliche Falle tappst wie die GALEP2 Leute, z.B. ich. Ich dachte zwar, das sei jetzt unter Windows etc. kein Thema, aber vielleicht doch. Schau mal nach was der Galep als Lesebuffer angibt (File oder RAM) und ob die Grösse korrekt gesetzt ist. Da hatte der Galep2 einen Bug mit der Puffergrösse. Die war falsch berechnet. Beim Einlesen klappt das wahrscheinlich, weil er da soundso viel liest, d.h. die Puffergrösse dann wahrscheinlich korrigiert ist. Irgendsowas könnte das sein. Einen Verify mit Buffer macht er mit eben nur z.B. der Hälfte der Daten, und das Ergebnis ist ja dann auch logischerweise OK.

Import-Script

02.05.2003, 09:18

Hallo Andreas, In den Optionen ist der Menüpunkt "Passe die Puffer-Endadresse beim Dateiladen an" aktiviert Hier die Anzeige der Bufferendadresse bei verschiedenen Aktionen: Start von Galep - 3FFFFF Bauteilauswahl FM27C040 - 07FFFF (524.287) Original Eprom auslesen - 07FFFF (524.287) Datei Laden - 13801B (1.277.979) oder auch - 1FFFFF (2.097.151) Da scheint wirklich so ein Problem zu sein oder ? Was soll ich nun machen und wie ist der Speicher eigentlich organisiert, denn das ist ja ein 4 MB Eprom, dann müssten diese Daten doch platz haben, oder wie ist das zu verstehen ? Gruss Martin

Import-Script

02.05.2003, 13:08

Eben, da haben die Burschen wirklich ein Problem. (seit 1994!!! traurig gell).. Also wichtig ist, dass der Buffer exakt so gross ist wie das Eprom, bei 4MB also 4*1024*1024 =4194304 Byte oder in HEX:400000 also 0...3fffff. Eine 3 mit fünf "F"s also. Das ist das einzig wahre. Ich könnte jetzt jedoch vermutmasseln, dass der 27c040 garkein 4MB Typ ist. Meiner Meinung nach müsste das ein 27c4001 sein. Dem Katalog nach ist das jedoch beides identisch, nur bezieht sich die Angabe auf MEGABIT, also sind beide Typen 512kByte*8. In diesem Fall hat dann der Galep Recht und Du hast zu kleine ROMs. Wenn also beim Datei-Laden schon mehr als 512kB herauskommen hast Du eindeutig zu kleine Chips.

Import-Script

05.05.2003, 11:31

Hi, erstmal vilen Dank für Deine rasche Antwort! Stimmt das mit dem Unterschied bei 27c040 und 274001, war immer der Meinung das ist das selbe ? Habe jetzt nachgeschaut und festgestellt, dass orginale Eprom´s auch die 27C040 sind, deshalb kommt mir das jetzt schon komisch vor, wass soll ich denn jetzt versuchen, habe nach Datei laden die Buffergrösse reduziert, aber dann hat der Baustein nicht mehr funktioniert. Wer kann mir da weiterhelfen ??? Gruss Martin

Import-Script

05.05.2003, 14:22

Hallo, das mit dem 4001 und 040 ist das gleiche! Sorry, wenns falsch rübergekommen ist. Die sind beide GLEICH ZU KLEIN! nämlich 512kByte und nicht 4 Megabyte. Wenn beim Datei-Laden schon 1,277 Megabyte kommen, dann passt´s schlicht und einfach nicht. Ich finde auch im Katalog so keine 4-MegaBYTE Eproms. Flashes etc. ja, meist dann aer auch 16bittig oder 32bittig organisiert 28F230 z.B. Auch bei Dallas-BatterieRAMs ist mit DS1200 bei 512kByte (8Bit) Ende.

Import-Script

22.05.2003, 08:15

Also ich schnall das nicht, der Hersteller gibt mir die Daten in Grösse von 1,277,980 bytes (Chksum $8900) für das 1.EPROM 27C4001 und 639,004 byte für das 2. EPROM. Das wäre scheinbar so in Ordnung. Was soll ich nun machen ??? Martin

Import-Script

22.05.2003, 15:16

Die Checksum sagt nicht allzu viel, wohl aber die Dateigrösse, nämlich 639Kilo BYTE!!! 4 Megabit /8 macht aber nur 512Kilo BYTE!!! - also zu kleines Eprom. Bei der 1,2 MegaByte Datei sieht´s noch übler aus. Frag mich, was für ein "Hersteller" Megabytes in Eproms packen will. Sorry, aber das passt nicht!!! in einen Chip.

Import-Script

22.05.2003, 20:03

Ahh jetzt hab ich es verstanden, beim Eprom wird die Dateigrösse in Bit angegeben deshalb /8 8bit=1byte ;) Danke für den Tip, jetzt wäre ich nur noch neugierig wieso ich dann so große Datenfile bekomme. Es handelt sich dabei um die Firma Cerberus (Siemens) und die schicken wohl an alle diese Files. Ich bekomme sie im Format *.r1m kann es sein das ich was falsch mache oder müßte die Datei anderswertig geöffnet werden ??? Gruss Martin

Import-Script

23.05.2003, 18:03

An der Idee ist was dran, dass es sich um eine Art S-Record oder Intel-Hex-File handelt. Dann bräuchtest Du in der Tat ein Toole, welches daraus die echten Binärdaten erzeugt. Das würde zumindest auch die irre Grösse erklären. Intel-Hex bläht um Faktor 4, Motorola S-Rec auch.

Import-Script

26.05.2003, 09:20

Villeicht kommt jetzt ja langsam die Lösung meines Problemes ans Tageslicht ;) Weißt Du zufällig einen Link wo man sich so ein Tool zum versuch runterladen kann? Villeicht hab ich dann mehr Glück beim Brennen ... Gruß Martin

Import-Script

26.05.2003, 10:00

ist doch wohl erst zu klären, wenn Du weisst, was .r1m ist. Das dürfte Dir die Firma Cerberus doch wohl am ehesten erklären können. Ansonsten mal mit einem Texteditor!!! in die Datei reinschauen. IntelHex und Mot-S sind ASCII Dateien, da kann man auch seitenweise Kommentare reinschreiben (zumindest bei Motorola); alles was nicht mit s1..s5 anfängt wird sowieso überlesen.

Import-Script

26.05.2003, 19:52

Hallo! Falls es Motorola Hex Dateien sind, bitte mal in *.mhx umbennenen. Danach läd der Prog-Studio Hex-Editor diese entsprechend. Falls es sich um Intel Hex Dateien handelt, in *.ihx umbenennen. Alle anderen Dateiendungen werden als Binärdateien geladen. Grüße André

Import-Script

26.05.2003, 21:31

@Andre: Könnt ihr Dosen-Spezies das auch mal ohne Endung??? (ist jetzt nicht bös gemeint, aber eine Datei ".IHX" zu nennen, nur damit das dann IntelHex-ist??? /sein soll /als solche interpretiert wird... Was machst Du mit ".AS" - Dateien? Weitermailen an mich??? Das kann doch nicht der Weisheit letzter Schluss sein. Welcher Filter wäre dann für ".r1m" zuständig??? Da bin ich <img src="http://progshop.com/elektronik/diskussion/messages/4982/7311.jpg" alt="dagegen">

Import-Script

26.05.2003, 22:47

@Andreas: Eine Binär Datei kann alle möglichen Zeichen enthalten und damit exakt wie eine Hex Datei aussehen. Eine automatische Erkennung erscheint mir daher schwierig... Hast Du da eine Idee? Ich baue diese dann gerne ein... Grüße André

Import-Script

27.05.2003, 08:35

Hi also wenn man eine Datei von Anfang bis Ende durchläuft und findet nach jedem <cr><lf> ein ':' (ausgenommen letzte Zeile) dann ist das mit allergrößter Sicherheit ein Intel Hex. Oder du gehst über das ganze File und schaust ob irgendwo was größeres als 0x7F auftaucht. Dann weißt du schonmal das es wahrscheinlich eine ASCII-Datei mit einem HEX-File MOT-S-Record oder ähnliches ist. Matthias

Import-Script

27.05.2003, 09:57

S11303802730A1042733A1052736A1062739A10761 S1130390273CA108273FA1092742CC03E3A63FBB82 S11303A0D5B70081A606BBD5B70081A65BBBD5B780 S11303B00081A64FBBD5B70081A666BBD5B7008127 S11303C0A66DBBD5B70081A67DBBD5B70081A62796 S11303D0BBD5B70081A67FBBD5B70081A66FBBD5BF S11303E0B70081A679BBD5B70081A6FF4A26FD8157 S11303F09B1A011B01A608CD04AB2E079A80A610F8 S1130400CD04AB981A012E01991B0136D7A610CD45 S113041004AB981A012E01991B0136D7A610CD04FE S1130420AB981A012E01991B0136D7A610CD04AB47 S1130430981A012E01991B0136D7A610CD04AB984A S11304401A012E01991B0136D7A610CD04AB981AB8 S1130450012E01991B0136D7A610CD04AB981A01C1 S11304602E01991B0136D7A610CD04AB981A012E84 S113047001991B0136D7A610CD04AB9D1A011B01AF S11304809A801A01811B0181AE099824041A012063 S1130490041B012000A60DAD124D36D75A26EC9D43 S11304A01A01A60EAD05A60EAD01819D9D4D4A26ED S10504B0FA81CB S10B07F8030003F003000300F9 S9030000FC Das ist Motorola S-Recors. Unschwer zu erkennen, bedeutung so in etwa: nehmen wir mal die drittletzte Zeile S1 heisst jetz folgen Daten, dann 05=5 Bytes, das letzte ist die Prüfsumme über die Zeile, dann die Bytes in ASCII. Letzte Zeile: S9 heisst jetzt folgt Ladeadresse: in diesem Fall 0300 und Startoffset (Stammt von 6805 CPU). Aber Deutlich wirds wohl, warum das Teil S-Record heisst; und vor allem wie man es erkennt.

Import-Script

28.05.2003, 17:31

Hallo! Also wie die Motorola und die Intel Dateien aussehen müssen, ist mir schon klar. Die Einladefunktionen habe ich dafür ja auch bereits vor längerer Zeit fertig geschrieben und eingebaut. Mit ging es nur darum, dass eine binäre Datei beliebig aussehen kann und damit exakt wie die obigen S-Records aussehen könnte. Damit wäre kein Unterschied zu erkennen. Grüße André

Import-Script

28.05.2003, 17:46

Hi und wie unwahrscheinlich ist das? Matthias

Import-Script

28.05.2003, 18:02

Sehr unwahrscheinlich, da hast Du schon recht. Es wird ja reichen wenn alle nicht bekannten Endungen automatisch erkannt werden und *.bin weiterhin immer als Binär-Datei geladen wird. Damit kann ich mich anfreunden... Werde es in dem kommenden Update umsetzen. Grüße André

Import-Script

28.05.2003, 19:40

Ich glaube, das hat was mit PC-Denke zu tun (leider). Was sind denn alle bekannten Endungen??? Ich denke, der Endungskram hat echt nur was mit der ehemaligen DOS-Vorgabe zu tun. Es gibt z.B. Read.me und Lies.das, da sieht man doch, dass es überhaupt keinen Sinn macht. Eine Datei Namens PikDa.me wäre damit automatisch englisch und eine .me Anwendung, was auch immer das sei??? Nun haben wir Europa und damit auch (Zeichensatzabhängig) T€ureDat.ein ???, die Mühe ist wohl ganz lieb gemeint, geht aber seit Win95 bzw. seit MAC(Uralt) total an der Sache vorbei. Der Anwender sollte sich einfach darüber im Klaren sein, dass eine .BM3 in einer 5erBMW eher nichts nutzt, trotz dass sein Prommer jetzt so schlau gemacht wird, dass er bei .BM5 automatisch ein 512er Eprom vorschlägt und bei .BM7 einen Flash (weiss Gott? (BMW!!!) welchen... Ich finde schon diese "Vorankreuzung" im ÖffnenMit Feld von Windows total daneben, alle Dateien default!!! mit Prog.xy zu öffnen. P.S. Wie kriegt man das Kreuzchen defaultmässig weg??? --> ist jetzt ernst gemeint. Wenn ich will, dass er das mit allen macht, dann sage ichs ihm schon per Ankreuz! explizit.