AT89C51RC Flash programmierung über API-Call

[Alex K. (adac0815)]

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

[Ralf A. (warpnine)]

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

[Thomas (Gast)]

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

[Alex Kerr (Gast)]

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.

[david reiher (Gast)]

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

[Ralf (Gast)]

@David:

Poste mal das Datenblatt zu deinem µC (oder einen Link).

Ralf