Hallo robo.fr,
nach langem Probieren und Untersuchen der Kommunikation über die Datenleitungen habe ich das Protokoll herausgefunden das dem Flashen zu Grunde liegt.
Hier ein Auszug meiner Dokumentation.
Code:
Protokoll:
DCE(Bootloader) DTE
--------------------------------------------------------
<switch on>
<-- send PAGEFRAME 1
ASURO_ACK -->
<-- send PAGEFRAME 2
ASURO_ACK -->
<-- send PAGEFRAME 3
ASURO_NAK -->
<-- send PAGEFRAME 3
ASURO_NAK -->
<-- send PAGEFRAME 3
ASURO_ACK -->
<-- send PAGEFRAME 4
ASURO_ACK -->
<-- send PAGEFRAME 5
. .
. .
. .
<-- send PAGEFRAME n
ASURO_ACK -->
<-- send end PAGEFRAME
<asuro is ready>
Legend:
ASURO_ACK 'OK' // page ok
ASURO_NAK 'CK' // page checksum error
ASURO_ERR 'ER' // asuro error
PAGEFRAME
byte PageNum
TAtmelRAMPage PageData
word PageCRC
Dabei sind auch einige Optimierungsrunden nötig gewesen um die Datenübertragung besser in den Griff zu bekommen. Das original Flashprogramm arbeitet scheinbar ziemlich stur sein Protokoll ab, wohingegen AsuroFlash.exe abhängig von evtl. auftretenden Störungen den Übertragungsdatenstrom steuert und deshalb verlässlicher flasht.
Deshalb habe ich das Proggi auch ursprünglich geschrieben, da ich ziemlich genervt war wie der original Flasher arbeitet.
AF ist auch in der Lage differentiell zu flashen, was mit dem original Proggi irgentwie nie funktuioniert hat. Das spart auch einiges an Übertragungsleistung, bzw. Zeit.
O.
Lesezeichen