Hi, habe folgendes Problem: Ich möchte den Philips P89C51RC2 durch einen Atmel AT89C51RC2 ersetzen. Sollte auch kein Problem darstellen. Applikation läuft normal an, kein Auffälligkeiten. Ich setzte In-Application Programmierung ein um die Software aus der Applikation heraus updaten zu können. Hier nun zwei Probleme. a) Der Aufruf der Funktion "Program Data Byte" kommt immer mit einem Fehler (also !=0) zurueck. Zu Testzwecken habe ich diese Abfrage rausgenommen und siehe da, das Flash ist komplett neu programmiert worden (Der entsprechende Flash-Block wird vorher gelöscht) ! b) Das Programmieren eines Bytes dauert erheblich länger als beim Philips P89C51. Laut Atmel sollte man die Funktion "Program Data Page" nehmen, habe aber keine 128Byte XRAM mehr frei und die Applikation soll ja auch erstmal kompatibel zum P89C51 bleiben. Sind diese Probleme bzw. Auffälligkeiten bekannt? Mache Ich hier was falsch? Danke schon mal für die Hilfe :) hier der Programmteil zur Programmierung: ;----------------------------------------------------------------------- -------- ; Programmierung eines Bytes in den Flashspeicher des uCs ; Aufruf aus 'C': boolean ProgramuCByte( word Adr, byte Val ); ; ; R6 = Highbyte, Adresse ; R7 = Lowbyte, Adresse ; R5 = Byte zu programmieren ; ;----------------------------------------------------------------------- -------- _ProgramuCByte: MOV R1,#02h ; IAP Call Nr. 2 MOV DPH,R6 ; Zieladresse, Highbyte MOV DPL,R7 ; Zieladresse, Lowbyte MOV A,R5 ; Wert (Val) MOV AUXR1,#20h ; ENBOOT setzen LCALL 0FFF0h ; IAP-Call MOV AUXR1,#00h ; ENBOOT zuruecksetzen SETB C ; Rueckgabe ueber Carry ; Carry 1 = ok. JZ Prog_2 ; Wenn Akku 0 = o.k dann ; Sprung nach Prog_2. CLR C ; Carry 0 = nicht o.k. Prog_2: RET
Guck mal auf der Atmel-Site nach den Errata-Sheets zum Chip und zum Bootloader. Ich meine mal etwas gelesen zu haben, dass der Wert, der nach einem erfolgreichen API-Call im Akku zurückgegeben wird, 00 sein soll, es aber nicht ist, obwohl das Programmieren okay war. Ralf
Gast
#334597
wie wäre denn ein Verify?
CLR C
MOVX A,@DPTR
SUB A,R5
JNZ xxx
CPL C
xxx: RET
Auserdem solltest du Interrupt Reg vor dem IAP Call sichern und die
Interupts sperren.
PUSH IE
CLR EA
....
....
POP IE
128 Bytes per PageProg geht beim RC2 sowiso nicht da gibts ein Errata
Ich habe jeweils 32 Bytes am Stück programmiert.
Insgesammt ist der Atmel flexibler, da das Löschen entfällt und keine
Segmentierung des Flashs existiert.
Thomas
Gast
#334598
Danke für die Hilfe! Ist tatsächlich ein Bug im Chip. Muss also ein Verify herhalten. Ich schreibe jetzt 16Byte mit "Program Data Page" und das scheint zu klappen. Ist erheblich schneller als über "Program Data Byte" die Bytes einzeln zu programmieren. Das wars zwar dann mit Kompatibilität zum Philips aber zumindest gehts. Alex.
Gast
#334599
morgen an alle! da die leute in diesem thread ja scheinbar ahnung von in-application programmierung haben, kann mir einer mal kurz die grundlagen/befehle dafür näher bringen? ich will auf einem ADuC847 kalibrierung im programmspeicher über die UART vornehmen. nutze dafür c auf dem accutron compiler für aspire. nu hab ich aber das problem, dass die controler dokus nur für asm geschrieben sind und ich in c keine ahnung hab wo meine werte im datenspeicher landen. von accutron hab ich noch nirgends ne richtige dokumentation gefunden. UART ist kein problem, brauche daher wirklich nur die grundlagen für die umprogrammierung. danke im vorraus david
Gast
#334600
@David: Poste mal das Datenblatt zu deinem µC (oder einen Link). Ralf