Eigentlich ist der Map Upload über das Nanocom sehr robust.
1. Das Nanocom liest die Map von der SD-Karte und packt sie in den internen Speicher
2: Das Nanocom schreibt die Variante (Der Teil ohne Fuel Maps, Fahrzeugspezifisch) und die Map.
3: Die ECU bootet, prüft die Prüfsummen, und schreibt, wenn die korrekt sind, 4 Bytes ins EEprom, in den Speicherbereich der Map. Nennen wir sie OK-Bytes.
5: Wenn diese 4 Bytes gesetzt sind, versucht die ECU das Programm zu laden und auszuführen, und meistens klappt das.
Jetzt das Problem:
Wenn man eine Map von einer ECU runterlädt, sind die 4 OK-Bytes ja korrekt gesetzt.
Jetzt ändert man die Map, dadurch werden neue Prüfsummen erzeugt, weil sich ja der Inhalt geändert hat.
Wenn man die Map nun komplett hochlädt sieht die ECU danach beim Starten gute Checksummen, korrekte OK-Bytes und startet. Perfekt.
Wenn der Transfer aber abbricht, NACHDEM die OK-Bytes geschrieben wurden, aber ein Teil der Map nicht überschrieben wurde, gibt es ein Problem:
Die ECU bootet, sieht die 4 korrekten OK-Bytes und startet das Programm. Dieses Crasht, und die ECU steht. Nanocom kommt nicht mehr drauf.
Wären die OK-Bytes in der Map vor dem Upload auf 0 gesetzt worden, hätte die ECU die (dann natürlich falschen) Prüfsummen kontrolliert, und wäre im Bootmode geblieben, wo sie vom Nanocom erreichbar ist.
Die XDF-Files von DiscoTD5 enthalten ein Plugin für TunerPro, dass beim Speichern der Maps die OK-Bytes auf 0 setzt. Mit den so erzeugten Maps sollte es schwerer sein eine NNN-ECU zu "bricken".
"Brick Proof" programming tool update | DiscoTD5.com
Wenn es trotzdem passiert ist muss man irgendwie die kaputte Map im EEPROM mit einer korrekten Version überschreiben. Die meisten haben dazu den Speicher ausgelötet, neu beschrieben und eingelötet, was natürlich mit Aufwand und Risiko verbunden ist.
Jetzt hat die ECU aber wie die Saab-Ecus, mit denen ich recht viel gemacht habe, die Möglichkeid, über den Prozessor (ein NXP MC68336) im Backround Debugging Mode (BDM) in den Speicher zu schreiben. Das Interface sind die 8 unbestückten Pads neben der CPU, da wo der Barcode bappt.
Programmer habe ich, ausgelesen habe ich den Speicher über dieses Interface auch schon, aber schreiben werde ich meine ECU nicht, da ich nur die eine habe. :-) Deshalb meine Suche nach einer (Nanocom) gebrickten NNN.
So könnte man eine NNN in wenigen Minuten entbricken, UND man könnte mit einem billigen JBDM-Interface OHNE Nanocom Maps auf die ECU kriegen.
Ich hoffe mich verständlich gemacht zu haben.
Gruss Holger
Kommentar