Guten Tag
Ich bearbeite ein Assembler Programm, dass ich nicht selber geschrieben 
habe. Meine Kenntnisse halten sich bis jetzt in Grenzen und deshalb 
verstehe ich folgender Programmteil nicht und weshalb ich es nicht 
builden kann. Das Programm war schonmal genau so fehlerfrei in Betrieb.
Programmteil:
    fill  (nop),TaskError-$
    org    0x0F9
TaskError
    movlw  b'00000001'
    BANKSEL  WDTCON
    movwf  WDTCON
    banksel  PORTA
    goto  $
Ergibt folgender Error:
Error[151]   D:\WORK\MOTUSANTRIEBFRONTEGO\MOTUSANTRIEBFRONTEGO_MAB.ASM
333 : Operand contains unresolvable labels or is too complex
Vielen Dank schon mal und Gruss
drumstick
  Die erste Zeile ist so wies aussieht ein Makro. Poste mal dessen Programmcode. Der Rest des Programmauschnitts schreibt 0x01 in WDTCON und geht in eine Endlosschleife, bis der Watchdog-Reset eintritt. Könnte sein dass der Assembler mit den beiden TaskError durcheinander kommt, da es einmal als Label und einmal als Variable vorkommt.
Hi Vielen Dank, Dieser Programmteil füllt doch die freien Speicherplätze!? Muss ich den Speciherbereich irgendwo im MPLab angeben? Im Anhang ist noch ne Beschreibung. Gruess drumstick
0x01 in WDTCON bewirkt, dass der WDT einen Vorteiler von 1:32 hat und der WDT eingeschaltet ist (sofern der WDT per Software einschaltbar ist; das steht dann im Bit WDTEN im CONFIG1 Word, dort kann man einstellen, ob der WDT immer aus ist oder ob er per WDTCON einschaltbar ist). Der Fill-Befehl füllt hier ab der aktuellen Stelle bis zum Flag Taskerror (0x0F9) den Speicher mit NOPs
Sascha schrieb: > Könnte sein dass der Assembler mit den beiden TaskError durcheinander > kommt, da es einmal als Label und einmal als Variable vorkommt. Definitiv nicht, der Ausdruck TaskError-$ aus der ersten Zeile bedeutet nichts anderes als die Subtraktion des ProgramCounter-Wertes von der Adresse des Labels TaskError. Resultat ist eine Konstante, keine Variable. M. B. schrieb: > 333 : Operand contains unresolvable labels or is too complex Welches ist denn die Zeile 333, aus deinem Posting geht das nicht hervor? Gruß, Edson
Das Config1-word hat den Wert:
  __CONFIG    _CONFIG1,  B'00100101011000'
also bit 2 hat den wert 0 = WDTEN ist disabled
Zeile 333:
    fill  (nop),TaskError-$
gruss
drumstick
  M. B. schrieb: > Zeile 333: > > fill (nop),TaskError-$ So, und jetzt fehlt nur noch die Auflösung des Makros fill... Falls das Makro in deinem Projekt gar nicht vorhanden ist, haben wir die Ursache der Fehlermeldung. "fill" wird dann als Label interpretiert und MPASM ärgert sich über das Komma nach dem (nop), da nach einem Befehl ein Operand erwartet wird. Gruß, Edson
Der Fehler hier ist, daß er die Adresse vom Label TaskError nicht kennt. Ich würde tippen, du versucht das Programm mittels Linker zu assemblieren und der Code braucht aber eine absoluten Assembler code. Aber, lass einfach die betreffende Zeile weg, denn dann wird der Code mit "addwf 0xff" gefüllt, in deinem Source ist es dasselbe, da danach eine Endlosschleife kommt (goto $) und das W-Register sowie die Statusbits (Carry/Zero)egal sind. Bei gelinktem Code trifft man die Codewörter "code" sowie "cblock" im Sourcefile
fill ist eine Assemblerdirektive. fill exp,count Fill füllt den Bereich mit exp und zwar count mal. und label-$ bedeutet, von hier bis zum Label.
Verstehe ich das richtig, fill ist ein Makro. Und ich muss es als .INC-Datei in den gleichen Projektordner speichern? Oder welches Format haben MAKROS? Falls ich dieses MAKRO nicht finde, kann ich das irgendwo beziehen? Danke Und Gruss M
Nein, fill füllt den Bereich. Es ist eine Assembler Direktive und kein Macro. Anstelle des Labels könntest du auch folgendes schreiben: fill 0,0x0f9-$ ; nop=0, ev könnte auch das das problem sein Trotzdem, ob ein NOP = 0 oder ein ADDLW 0xFF = 3FFF verwendet wird, ist in diesem Code egal, einfach die Zeile fill weglöschen. Der einzige Unterschied ist, daß man bei 3FFF nachträglich noch code reinpatchen kann, aber wenn du die codeprotection verwendest, ist das auch nicht mehr möglich.
Wenn du nichts schreibst, und einfach die org verwendest, dann wird steht da halt 3FFF drin was der Opcode für "addlw 0xff" also "addlw -1" ist.
Also die Zeile mit dem fill hab ich jetzt ausgeklammert. Folgender 
Fehler erhalte ich jetzt:
Programmteil:
    org  0x2100
    de  0x00,0x00,0x00
    de  0x00
    de  0xFF
    de  0xFF
    de  0x00,0x00,0x00
    de  0x00,0x00
    de  0x00
    de  0x00
    de  0xFF
    de  0x00
    de  0x00
;-----------------------------------------
  ;  fill 0x00,0x21D0-$
;------------------------------------------
    org  0x21D0
    dt  "HAWA AG Ver. 1.0"
    org  0x21E0
    dt  "Antrieb.asm     "
    org  0x21F0
    dt  "240120061200"
    de  0x00,0x00,0x00
;-----------------------------------------
    org  0x21FF
    de  0x00
    end
Fehlermeldung:
Error - section '.org_1' can not fit the absolute section.
Section '.org_1' start=0x00000004, length=0x0000010e
Was bedeutet das??
Danke und Gruss
M.
  Die Assembler Direktive fill kommt viermal im Programm vor! Einmal wie gerade geposted in einer Tabelle. Und da tritt der Fehler mit dem Linker auf.
Chris schrieb: > Nein, fill füllt den Bereich. Es ist eine Assembler Direktive und kein > Macro. Oh, sorry für meine Fehlinterpretation. Ich arbeite seit geraumer Zeit nicht mit MPASM. Gruß, Edson
Hallo Wenn jemand diesen Error genauer erklären könnte, wäre super! 333 : Operand contains unresolvable labels or is too complex Vielen Dank und Gruss M. B.
Hallo, pass auf, wenn du im EEprom Fill verwendest, dann ist das was anderes als auf der von dir beschriebenen Codestelle. Adressen ab 0x2100 sind EEprom. Ansonsten steht da FF drin und du erwartest warscheinlich ein 0. Ob da ein "dt" = retlw zulässig ist, weiß ich auch nicht recht, bzw was da dann effektiv in das EEprom landet.
ganz einfach, der Label kann nicht aufgelöst werden, warscheinlich da 
ein object File erstellt wird, welcher dann erst gelinkt wird, und 
deshalb
steht die Adresse für die Berechnung nicht fest, welche aber für die
Assemblerdirektive gebraucht wird. Der Label wird die Adresse 0x0f9 
haben.
Wenn du aber "fill 0,0x0f9-$" schreiben würdest, dann dürfte der 
Assembler kein problem damit haben.
fill  (nop),TaskError-$
    org    0x0F9
TaskError
  Hallo Vielen Dank für Eure Hilfe! Nun kommt folgende Meldung beim programmen und, wenn ich auf ok klicke und nacher ein verify mache tritt der Fehler ICD0161 auf. Was bedeutet dies? Hab die Einstellungen schon überprüft! Danke und Gruess M. B.
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.