Reste Bootlader Sprungadresse

[Harry (Gast)]

Hallo

Ich habe folgendes Problem.
Auf meinen Pic33fj läuft ein Bootloader ab der Adresse 0x2AA00,
Nun möchte ich in meiner Applikation den Bootloader aufrufen.
Wie komme ich zu dieser Adresse hin? Bzw. Wie muss ich den Zeiger dahin 
definieren.
Ein kleines Beispiel wäre super
Meine Applikation läuft ab der Adresse 0x200


Besten Dank

[Fred R. (Firma: www.ramser-elektro.at/shop) (fred_ram)]

asm volatile ("goto 0x2AA00");

Oder:

 void GoTo(unsigned int addr)
 {
    asm volatile ("goto %0" : : "r"(addr));
 }

Oder:

 void (*fptr)(void);

 fptr = (void (*)(void))0x2AA00;
 fptr();

[Jan H. (janiiix3)]

void (*goto_bootloader)(void) = 0x2AA00;

Brauchst nicht noch einen extra Zeiger definieren.

Rufst du dann einfach mit

goto_bootloader();

auf.

[Harry (Gast)]

Danke für die schnelle Antwort.
Es geht soweit nur ein Problem habe ich.
Wenn ich die Applikation aufgespielt habe Startet er meist wieder beim 
Bootloader.
Im Bootloader ist der Reset mit goto 0x200 definiert. In meiner 
Applikation beginnt der Code / ist im Linker File auch 0x200 definiert.

Was muss ich da noch beachten.

[Nico W. (nico_w)]

Bei meinem STM ist auf der Sprungadresse der Stackpointer. Der Code 
fängt dort, bei 32 Bit, dementsprechend 4 später an.

[Harry (Gast)]

Nico W. schrieb:
> Bei meinem STM ist auf der Sprungadresse der Stackpointer. Der
> Code
> fängt dort, bei 32 Bit, dementsprechend 4 später an.


Ich verwende einen ds33fj ist es dort wohl auch so

[Harry (Gast)]

Super es Funktioniert soweit mit einen Beispiel Applikation.
Nun Folgendes wenn ich meine Applikation aufspiele die aus mehreren C 
Fieles besteht macht er ständig einen Reset. Selbst wenn ich nur die 
Main .c und ein Fiele mit den Port init. bleibt er beim Bootloader 
hängen.
Der Bootloader ist nicht in der Applikation vorhanden. Sonder den 
übertrage ich über den ICD3 als erstes dann die Applikation über die 
Serielle Schnittstelle.

[Adam P. (adamap)]

Hallo Harry,

also das mit der Sprungadresse, Stackpointer und 4 Byte Offset ist 
zumindest bei ARM (Cortex) Controllern so.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABIFJFG.html

Da befindet sich an Adresse 0x00000000 die Vector Table und in dieser 
ist in den ersten 4 Byte halt der Init Wert für den Stackpointer.

Ich weiß jetzt leider nicht welchen ds33fj du genau hast, aber ein 
kurzer Blick ins Datenblatt lässt mich ahnen, dass es bei dir nicht so 
sein wird.
Außerdem hast du ja einen 16-Bit µC.

Siehe Seite 35:
http://ww1.microchip.com/downloads/en/DeviceDoc/70286C.pdf

Da sieht der Aufbau z.B. so aus:
0x000000   GOTO Instruction
0x000002   Reset Address
0x000004   Interrupt Vector Table
0x0000FE   Reserved
0x000100   Alternate Vector Table

Der Stackpointer ist bei dir im CPU Register W15, also im letzten der 16 
vorhandenen.

Vllt. hilft dir das weiter.

[Adam P. (adamap)]

Also das versteh ich jetzt nicht:

- "Super es Funktioniert soweit mit einen Beispiel Applikation."
- "...macht er ständig einen Reset."
- "...bleibt er beim Bootloader hängen."

Funktioniert es nun oder nicht und wenn, was funktioniert wenn du sagst 
es funktioniert doch nicht?
Und "hängen bleiben" ist nicht "reset".
Oder hast du ein Watchdog der beim "hängen bleiben" ein Reset 
durchführt?

[Harry (Gast)]

Adam P. schrieb:
> Also das versteh ich jetzt nicht:
>
> - "Super es Funktioniert soweit mit einen Beispiel Applikation."
> - "...macht er ständig einen Reset."
> - "...bleibt er beim Bootloader hängen."
>
> Funktioniert es nun oder nicht und wenn, was funktioniert wenn du sagst
> es funktioniert doch nicht?
> Und "hängen bleiben" ist nicht "reset".
> Oder hast du ein Watchdog der beim "hängen bleiben" ein Reset
> durchführt?
Die Beispiel Applikation funktioniert sprich in der Main einfach paar 
LEDs einschalten. Aber die eigentliche Applikation für das der 
Bootloader gedacht ist lässt sich aufspielen aber sie wird nicht 
ausgeführt.
Watchdog ist ausgeschaltet.

[Adam P. (adamap)]

Kannst du dann nicht einfach mal den Ablauf im Bootloader Debugen und 
Step by Step mal durchklicken, dann müsstest du den Fehler recht schnell 
finden.

Ich vermute mal, dass im Bootloader die falsche Adresse geladen wird und 
wenn die dann angesprungen wird, steht da nichts womit der µC was 
anfangen könnte.

Kannst dir ja mal dein *.bin File der "Applikation" im Hex-Editor öffnen 
und im Debug Modus den Inhalt deines Flashes, ob der Code auch wirklich 
im Flash an der gewünschten Stelle steht.

[Harry (Gast)]

Hallo

nach dem Reset Startet der Bootloader der bei der Adresse 2A200 anfängt.
Der Rücksprung vom Bootloader zu Applikation wird mit einem goto auf 
202hex Befehl gesprungen.
In der Applikation wird dem Linker gesagt das der Programmcode XR bei 
200hex anfangen soll.
Dies Funktioniert nur teilweise
Hier mal der Code im Disasambler wo es nicht Funktioniert
NOP
NOP
200hex   RETLW #0x0, W0
202 hex  BTG W3, #15
204hex   MOV.D W8, [W15++]
205hex   MOV.D W10, [W15++]
206hex   MOV W12, [W15++]

Sobald ich eine Zeile in der Applikation auskommentiere wo was berechnet 
werden soll da Funktioniert der Sprung und es läuft die Applikation.
Hier mal der Code im Disassambler ab 200hex

255  001FC  005DDE    NOP
256  001FE  005DDE    NOP
257  00200  050000    RETLW #0x0, W0
258  00202  FA0000    LNK #0x0
259  00204  801621    MOV LATA, W1
260  00206  2FF000    MOV #0xFF00, W0
261  00208  608000    AND W1, W0, W0

Hier geht es.

Warum ist das denn so

[Harry (Gast)]

glaub ich hab es gefunden.
Im Reset Vektor ändert sich die Einsprungadresse je nachdem was ich für 
Code hinzufüge.
Wie kann ich denn festlegen das die Einsprungadresse für die gesamte 
Applikation gleich bleibt.

[Dr. Reset (Gast)]

Der Vektor ändert sich? Das erzähl mal "Microchip".
Der Verktor hat immer EIN und DIE SELBE Adresse.

[Harry (Gast)]

Dr. Reset schrieb:
> Der Vektor ändert sich? Das erzähl mal "Microchip".
> Der Verktor hat immer EIN und DIE SELBE Adresse.

Der Vektor vom Reset selbst nicht. Nur die Adresse wohin er springen 
soll.
Muss ich da den Stack neu einlesen?

[Harry (Gast)]

Adam P. schrieb:
> Hallo Harry,
>
> also das mit der Sprungadresse, Stackpointer und 4 Byte Offset ist
> zumindest bei ARM (Cortex) Controllern so.
>
> http://infocenter.arm.com/help/index.jsp?topic=/co...
>
> Da befindet sich an Adresse 0x00000000 die Vector Table und in dieser
> ist in den ersten 4 Byte halt der Init Wert für den Stackpointer.
>
> Ich weiß jetzt leider nicht welchen ds33fj du genau hast, aber ein
> kurzer Blick ins Datenblatt lässt mich ahnen, dass es bei dir nicht so
> sein wird.
> Außerdem hast du ja einen 16-Bit µC.
>
> Siehe Seite 35:
> http://ww1.microchip.com/downloads/en/DeviceDoc/70286C.pdf
>
> Da sieht der Aufbau z.B. so aus:
> 0x000000   GOTO Instruction
> 0x000002   Reset Address
> 0x000004   Interrupt Vector Table
> 0x0000FE   Reserved
> 0x000100   Alternate Vector Table
>
> Der Stackpointer ist bei dir im CPU Register W15, also im letzten der 16
> vorhandenen.
>
> Vllt. hilft dir das weiter.



Das hat doch mit dem Stack was zu tun. Ich verstehe es einfach nicht.
.stack :
   {
     __SP_init = .;
     . += 0x100;    << Please note the additional ';' symbol
     __SPLIM_init = .;
     . += 0x20;    << Please note the additional ';' symbol
   } >data

[Steffen R. (steffen_rose)]

Du schilderst sehr wirr und so kann dir niemand wirklich helfen.
Zuallererst solltest du mal dein genaues Derivat benennen.

Dann ist mir Unklarr, wie bei dir der Bootloader immer die Oberhand 
gewinnen kann. Ich vermute mal, dass du eine Dual Partition CPU 
verwendest? Dann wären die Optionbits interessant.

So ganz passt dann aber deine Alternative Vectortabelle nicht ins Bild.

Die Adresse im Resetvector verschiebt sich immer zum Programmeinstieg. 
Und den kennt nur der Linker. Da beim dsPic33 ein GOTO im Resetvector 
steht, wäre das die konstante Stelle zum Springen.

Allerdings ist mir noch sehr unklar, wie dein System aufgeteilt ist und 
welche der vielen möglichen Szenarien bei Dir genutzt werden.

Und bitte: Zwischen Cortex-M und dem dsPic33 gibt es hier eher keine 
Gemeinsamkeiten. Und vielleicht auch ein wenig dran denken, dass der 
dsPic33 eher eine Havard-CPU ist.