Hallo, ich möchte bei einer Elektronik die mit einem Fujitsu MC 16FX arbeitet die Baudrate erhöhen. Ich habe auch schon die passenden zwei Bytes (des BGR3 Registers) die getauscht werden müssen ermittelt. Es ist leider nur die FW Datei in mit .MHX Endung vorhanden. Diese ist wohl im S-Format (Notorola) geschrieben. Dieses Format arbeitet mit Checksummen und leider müssten ab der Änderung alle CS neu berechnet werden. Gibt es dafür ein feriges Progemm oder einen Editor der diese Aufgabe erledigt? Habe es schon mit Convertern versucht aber leider ohne Erfolg (es kommt dann Fehlermeldung das MHX-Datei fehlerhaft ist). Gruß Jackson
Hi Mit objcopy (aus den GNU binutils) sollte das kein Problem sein. Zuerst das srec in eine reine Binärdatei umwandeln, die Bytes entsprechend anpassen und dann wieder zurück nach srec. Evtl. wird die srec Datei dann etwas größer. Oder aber du änderst die Bytes direkt im srec und passt die Prüfsummer der Zeile an. Die Prüfsummer bezieht sich immer nur auf die jeweilige Zeile. http://de.wikipedia.org/wiki/Srec Matthias
Bist du mit der Prüfsumme sicher? Bei meiner Beispielrechnung klappte es nur wenn ich die Prüfsumme der vorherigen Zeile mit eingerechnet habe...
Hi Ja, bin mir sicher. Der Wikipediaartikel bestätigt das dann nochmal. Kannst ja mal das srec und die zu ändernde Position posten. Matthias
Hallo, anbei der Code:
1 | S214FE1A9AD060327293063316FE03D160287273063E |
2 | S214FE1AAA7293060C3862806F0DCBFEBBFEF103D135 |
3 | S214FE1ABA6013BBFE5B5679DD53507971DF51791799 |
4 | S214FE1ACADA535379D0096608004808F0135A2C0DE3 |
Die Hexdaten: 5679DD535 in der dritten Zeile müssen in 5679EE29 geändert werden. Gruß
Hi da passt was nicht zusammen. Die zwei Datensätze haben nicht die gleiche Länge. Matthias
hier nochmal ein größeres Stück...
1 | S210FE1A2E05BBFE7633065F03096608045F |
2 | S214FE1A3A719F040171B3FC7193067073FCFE124328 |
3 | S214FE1A4AFF1C7033067013FC180100000060086065 |
4 | S214FE1A5A067193FC703306096608004F30715F0400 |
5 | S214FE1A6A01659618FE651F19FE6C42625F30096BA9 |
6 | S214FE1A7A0802525179D32CF00771DF51791060F2C1 |
7 | S214FE1A8AD0535379D04908658C15FE729306F10336 |
8 | S214FE1A9AD060327293063316FE03D160287273063E |
9 | S214FE1AAA7293060C3862806F0DCBFEBBFEF103D135 |
10 | S214FE1ABA6013BBFE5B5679DD53507971DF51791799 |
11 | S214FE1ACADA535379D0096608004808F0135A2C0DE3 |
12 | S214FE1ADA4C65021AFE5D3BE803FE03D1600360E92D |
13 | S214FE1AEAD0096608004F01719F04015B2C0DBB06E8 |
14 | S214FE1AFAF004BB08F102601FBB065B2E0DBB08494D |
15 | S214FE1B0A08737F08015A2E0D98D1285B2E0D72880F |
16 | S214FE1B1A5352796C7853795F01096608004F01487B |
17 | S214FE1B2A08F1066C5853796012737F08015A2E0D17 |
18 | S213FE1B3A98D1285B2E0D72885352795F01096B86 |
19 | S214FF810A0000000000000000000000000000000061 |
20 | S214FF811A0000000000000000000000000000FF074B |
21 | S214FF812A0000000000000000000000000000000041 |
Hallo Michael S., ich würde Dir die Software von Galep empfehlen. Die kann auch in einer Demoversion MHX Files einlesen und Speicherbereiche verändern und diese dann wieder als MHX File ausgeben. Grüße
Hallo, danke für den Tipp mit Galep, der kann das tatsächlich... Aber leider ist das neue mhx-File nach dem speichern ca. 1.5MB groß (das org. nur 31KB). Und wenn ich das über den Updateflasher einspielen will gibt er mir Fehlermeldung das das mhx-File beschädigt ist. Also bin ich immer noch nicht weiter... Im Anhang befindet sich die org. MHX (einfach JPG-Endung entfernen) Vielleicht hat ja noch jemand ne Lösung für mich... Gruß Jackson
Hi hättest du mir darauf geantwortet als ich dich darauf hingewiesen habe das die auszutauschenden Daten unterschiedlich lang (4 zu 4,5 Byte) sind hätte ich dir sicher helfen können. Evtl. schaust du nochmal nach. Matthias
Hallo Mattihas, jetzt verstehe ich erst was du von mir woltest... Natürlich sind beide Datensätze gleichlang ich habe mich nur vertippt! :-( 5679DD53 müssen in 5679EE29 geändert werden... Gruß Jackson
Hi hier der diff der Originaldatei und der entsprechend geänderten
1 | --- SL-Tiny.mhx 2010-08-25 14:01:43.857550408 +0200
|
2 | +++ SL-Tiny.mod.mhx 2010-08-25 14:13:15.020051856 +0200
|
3 | @@ -473,7 +473,7 @@
|
4 | S214FE1A8AD0535379D04908658C15FE729306F10336 |
5 | S214FE1A9AD060327293063316FE03D160287273063E |
6 | S214FE1AAA7293060C3862806F0DCBFEBBFEF103D135 |
7 | -S214FE1ABA6013BBFE5B5679DD53507971DF51791799
|
8 | +S214FE1ABA6013BBFE5B5679EE29507971DF517917B2
|
9 | S214FE1ACADA535379D0096608004808F0135A2C0DE3 |
10 | S214FE1ADA4C65021AFE5D3BE803FE03D1600360E92D |
11 | S214FE1AEAD0096608004F01719F04015B2C0DBB06E8 |
Einfach die Prüfsumme für die Zeile neu berechnen und gut. Und hier die Ausgabe von srec_info was zeigt das die Prüfsummer korrekt ist.
1 | $ srec_info SL-Tiny.mod.mhx |
2 | Format: Motorola S-Record |
3 | Header: "SL-Tiny-CAN1" |
4 | srec_info: SL-Tiny.mod.mhx: 141: warning: data records not in strictly ascending |
5 | order (expected >= 0xFE09E9, got 0xFE0000) |
6 | Execution Start Address: 00000000 |
7 | Data: FE0000 - FE0002 |
8 | FE0004 - FE0005 |
9 | FE0008 - FE03FE |
10 | FE0400 - FE158A |
11 | FE158C - FE27A0 |
12 | FE27A2 - FE27DB |
13 | FF8000 - FF8060 |
14 | FF8062 - FF80AC |
15 | FF80AE - FF80C0 |
16 | FF80C2 - FF8139 |
17 | FFFF54 - FFFFDF |
Matthias
Hat geklappt, Danke dir! Ich hatte bei meinen versuchen den Wert für die Länge der Bytes nie mit eingerechnet... Gruß Michael
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.