bel-dateien werden geladen aber nicht korrekt gestartet

[PIC18F2550]

im belflasch.spin gefunden.

Code: Alles auswählen

  repeat i from 1 to 7                                  'alle anderen cogs anhalten
    ifnot i == cogid
      cogstop(i)

Sollte vieleicht so sein.

Code: Alles auswählen

repeat i from 0 to 7

Sonnst bleibt COG0 immer aktiv, das könnte das Problem beim laden von bin datein erklären.

[drohne235]

Code: Alles auswählen

  repeat i from 1 to 7                                  'alle anderen cogs anhalten
    ifnot i == cogid
      cogstop(i)

  dira := 0                                             'diese cog vom bus trennen
  cognew(@loader, plen)

  cogstop(cogid)                                        'cog 0 anhalten

Der Code geht ja noch weiter... Mein Gedanke dabei: auf COG 0 läuft ja dieser Code, welcher alle anderen COG's anhält, in der nächsten freien COG dann den Loader startet (cognew(@loader, plen)) und zuletzt sich selbst beendet (cogstop(cogid) ).

Müsste doch so funktionieren, oder? Mach mal bitte als Test folgendes: erzeuge mal einen EEPROM-Code mit 32 KB und schau ob der läuft.

[PIC18F2550]

Deine Routine geht davon aus das der Spinnteil immer auf COG0 läuft.

Das ist bei einem hartware reset warscheinlich immer der fall.

Bei einem Software reset scheint der prop alle COG's zu killen und dann aber den nächsten freien zu verwenden.
Das ist nicht immer COG0.
danngeht das nicht mehr auf.

Mal eine kleine frage Auf welchen COG läuft "mgr_load" nach dem es das neue File geladen und gestartet hatt?

Ich hatte ein etwas ähniches problem und habe es so besser in den Griff bekommen.
Muss aber immernoch einige im eeprom format behandeln.

mal ein auszug aus meinem Loder

Code: Alles auswählen

CON
_CLKMODE     = XTAL1 + PLL16X
_XINFREQ     = 5_000_000

PUB mgr_load|i                                          'cmgr: bellatrix-loader
  cognew(@L000, 0)

DAT
L000                    org     0
                        mov     dira,   LDIN                'bus auf eingabe schalten
                        mov     outa,   LM_0                'bus inaktiv
                        ' clear hRAM
                        mov     Lreg_a,  LCLS               '32k löschen
                        mov     Lreg_b,  #0                 'adresse ab 0
L001                    rdlong  Lreg_b,  #0
                        add     Lreg_b,  #1                 'adresse + 1
                        djnz    Lreg_a,  #L001
#ifdef Zerberus
                        ' COG-ID als info für Gesperrte COG's
                        cogid   Lreg_a
                        wrbyte  LSLOT,   Lreg_a
                        ' SLOT-Basis setzen
                        add     LSLOT,   #3
                        call    #Lget1                       'M1-wert(adresse) einlesen

[drohne235]

Bei einem Software reset scheint der prop alle COG's zu killen und dann aber den nächsten freien zu verwenden.
Das ist nicht immer COG0.
danngeht das nicht mehr auf.

Mal eine kleine frage Auf welchen COG läuft "mgr_load" nach dem es das neue File geladen und gestartet hatt?

Gute Frage. Ich denke der Loader wird in COG1 gestartet (hab ich aber nie geprüft) empfängt den neuen Code über den Bus und startet ihn in COG 0? Hab ich auch nie geprüft und das könnte wirklich Ursache von Problemen sein. Müsste man mal einen kleinen Testdriver schreiben, der die eigene COGID ausgibt. Wenn man den per bload startet, kann man ja mit Gewissheit sagen wo er landet. Kann ich aber grad nicht probieren, hab hier in der Firma leider (noch) keinen Hive...

[PIC18F2550]

Ich habe gerade mein bellflash.spin von 1 auf 0 geändert.
Jetzt kann ich auch die bin datei'n von meinem neuen Treiber laden und muss nicht mehr als EEPROM datei abspeichern.

[drohne235]

Ich habe gerade mein bellflash.spin von 1 auf 0 geändert.

Rätselhafte Worte in der Dunkelheit...

Was meinst du konkret?

[PIC18F2550]

Kiste auf Glaskugel raus -->>belflash.spin

Code: Alles auswählen

  repeat i from 1 to 7                                  'alle anderen cogs anhalten
    ifnot i == cogid
      cogstop(i)

  dira := 0                                             'diese cog vom bus trennen
  cognew(@loader, plen)

  cogstop(cogid)                                        'cog 0 anhalten

aus

Code: Alles auswählen

  repeat i from 1 to 7                                  'alle anderen cogs anhalten

wird

Code: Alles auswählen

  repeat i from 0 to 7                                  'alle anderen cogs anhalten

[drohne235]

Hmm, wenn das funktioniert, was ja nach deinem Test nicht zu bezweifeln ist: Warum funktioniert es? Im Prinzip beendet sich die COG ja dabei selbst und der Loader sollte überhaupt nicht gestartet werden!?

[PIC18F2550]

Wenn i nicht COG0 ist kann dieser wesentlich schneller arbeitete Code den frisch geladenen Code noch vor dessen Abschaltung beschädigen.
Daher erst alle COG'S. Stop dann Code laden dann diesen starten und im Anschluss Selbstmord.

[drohne235]

Wenn i nicht COG0 ist kann dieser wesentlich schneller arbeitete Code den frisch geladenen Code noch vor dessen Abschaltung beschädigen.
Daher erst alle COG'S. Stop dann Code laden dann diesen starten und im Anschluss Selbstmord.

Versteh ich nicht: Wenn ich alle COG's stoppe, dann läuft auch der Code nicht mehr, welcher die neue COG mit dem Loader starten soll.

Code: Alles auswählen

  repeat i from 0 to 7                                  'alle anderen cogs anhalten
    ifnot i == cogid
      cogstop(i)

Nehmen wir an, der Maincode nach einem Reset läuft auf COG0 (was wahrscheinlich ist), so wird schon beim ersten Schleifendurchlauf cogstop(0) ausgeführt, und der Hauptcode (damit auch obige Schleife selbst) wird beendet. Schon beim ersten Durchlauf sollte also einfach Ruhe sein.

Der folgende Code...

Code: Alles auswählen

  dira := 0                                             'diese cog vom bus trennen
  cognew(@loader, plen)

  cogstop(cogid)                                        'cog 0 anhalten

...wird also normalerweise überhaupt nicht ausgeführt und somit der Loader auch nicht geladen werden.

Oder stehe ich da auf dem Schlauch?