Hallo zusammen Ich versuche mich gerade an der STM32_USB-Host-Device_Lib_V2.2.0 für den STM32F105RBT6. Ich versuche einen virtuellen Comport zu erzeugen. Ich bin inzwischen soweit, dass ich den Code compilieren kann und soweis alles stimmen sollten. Wenn ich nun das Board mit dem PC verbinde, dann erscheint kurz das Device bzw. der Comport im Gerätemanager. Leider geht dann der STM32 in den BusFault handler. Nun möchte ich versuchen, herauszufinden weshalb dies so ist. Wie gehe ich hier am besten vor? Ich verwende Atollic True Studio Danke schonmal.
Update Wenn ich nach dem BusFault in Atollic auf Restart clicke und dann nochmals run drücke, dann funktioniert der ComPort nach dem dritten bis vierten Versucht, und es kommt kein BusFault mehr. Auf dem Host befindet sich dann aber ein nicht funktionierender COM9 und zusätzlich kommt dann ein funktionierender COM10 hinzu. Es scheint also so als ob die Library oder sonst was beim ersten mal noch nicht "bereit" gewesen wäre. ----- Update Wenn ich VBUS-Sensing aktiviere, dann springt er sofort in den BUS-Fault sobald ich PA9 (VBUS Sensing) mit 3.3V verbinde.
:
Bearbeitet durch User
Aus ARM DDI0403: B3.2.18 BusFault Address Register, BFAR The BFAR characteristics are: Purpose Shows the address associated with a precise data access fault. Usage constraints Valid only when BFSR.BFARVALID is set, otherwise reads as UNKNOWN. Configurations Always implemented. Attributes See Table B3-4 on page B3-652. Hättest Du aber auch selber finden können.
Siehe auch: www.keil.com/appnotes/files/apnt209.pdf Ggl: cortex-m3 find address bus fault
Angehängte Dateien:
-
busfault.png
71 KB -
Assembly.png
40 KB -
REG.png
28 KB
Danke für eure Antworten. BFARVALID ist 0x01 und BFAR ist: 0x1fff7a10 Wenn ich das richtig sehe, dann zeigt die Adresse auf einen reservierten Bereich. Weiss jemand mehr über dieses Verhalten? UPDATE: Ich habe noch die Registerwerte angehängt. MSP zeigt auf den RAM-Bereich. Warum auch immer.
:
Bearbeitet durch User
Claudio H. schrieb: > Danke für eure Antworten. > > BFARVALID ist 0x01 > und BFAR ist: 0x1fff7a10 > > Wenn ich das richtig sehe, dann zeigt die Adresse auf einen reservierten > Bereich. > > Weiss jemand mehr über dieses Verhalten? > > UPDATE: > > Ich habe noch die Registerwerte angehängt. > MSP zeigt auf den RAM-Bereich. Warum auch immer. Warum sollte ein Stackpointer nicht in den RAM Bereich zeigen? Warum ein Disassembly des RAM? Warum nicht bei 0x8003d22!, wo der PC hinzeigt? Weshalb könnte die angemeckerte in R3 stehen? Etwa weil bei 0x8003d22 LDR Rn,[R3] oder STR Rn,[R3] steht? BTW, SP ist ein Alias von MSP oder PSP, je nach Prozesser-Zustand.
:
Bearbeitet durch User
Angehängte Dateien:
-
Assembly2.png
45 KB -
MMFAR.png
7,4 KB -
CFSR.png
11 KB
Carl D. schrieb: > Warum nicht bei 0x8003d22!, wo der PC hinzeigt? Hab ich sogleich angehängt. Ist die Adresse des BusFault handlers. Carl D. schrieb: > Weshalb könnte die angemeckerte in R3 stehen? Hier beginnt Neuland für mich. Ich habe (noch) zu wenig Grundwissen um die genauen Abläufe der Register zu verstehen. Dies möchte ich ändern, und versuche deshalb den Fehler zu finden und so auch mein Verständnis für die grundlegendsten Abläufe zu erweitern. Carl D. schrieb: > Etwa weil bei 0x8003d22 LDR Rn,[R3] oder STR Rn,[R3] steht? Wie meinst du das? LoadRegister Rn in R3? ---- in MMFAR steht ebenfalls noch eine Adresse. Jedoch die gleiche wie in BFAR
:
Bearbeitet durch User
Johann L. schrieb: > 0x1fff7a10 Im Dissassembly gehts nicht. Im Memorybrowser steht da r3. Interessant, hab ich so noch nie gesehen. Bedeutet dies, dass das Register R3 an dieser Adresse ist oder was? Macht dies überhaupt sinn? Die Register sind ja fix im Core drinn und nicht an einer Adresse oder? Die Adresse liegt ja eigentlich im reservierten Bereich laut MemoryMap. Vermutlich kommt daher auch der BusFault. Fragt sich aber, was auf diese Adresse zugreifen möchte.
:
Bearbeitet durch User
>Fragt sich aber, was auf diese Adresse zugreifen möchte.
Dann schau halt auf einem der Stacks oder im Link-Register nach, wo er
sich rumgetrieben hat, bevor er im Fault-Handler gelandet ist.
Siehe auch "Determining where the exception occurred" in der oben
erwähnten Keil Appnote.
>Bedeutet dies, dass das Register R3 an dieser Adresse ist oder was? >Macht dies überhaupt sinn? Die Register sind ja fix im Core drinn und >nicht an einer Adresse oder? Anstatt Dich wilden, unfundierten Spekulationen hinzugeben, solltest Du Dich lieber an die Dok halten.
Beitrag schrieb: > Dann schau halt auf einem der Stacks oder im Link-Register nach, wo er > sich rumgetrieben hat, bevor er im Fault-Handler gelandet ist. > > Siehe auch "Determining where the exception occurred" in der oben > erwähnten Keil Appnote. Habe ich versucht. LR: 0xfffffff1 = 11111111111111111111111111110001 Im PDF: The current link register LR contains the EXC_RETURN value for the exception being serviced and this value indicates which stack holds the preserved register values from the application context. If bit 2 of the EXC_RETURN is zero then the main stack (MSP is saved) was used, else the process stack was >used. Bei mir ist bit 2 = 0 dies deutet an, dass der main stack die korrekten Registerwerte enthält. Der MSP zeigt auf: 0x2000fedc Dies ist im dissassembly:
1 | 2000fedc: vhadd.u8 d2, d0, d0 |
1 | 2000febc: lsls r4, r1, #12 |
2 | 2000febe: movs r0, #0 |
3 | 2000fec0: lsls r4, r1, #12 |
4 | 2000fec2: movs r0, #0 |
5 | 2000fec4: lsls r0, r6, #7 |
6 | 2000fec6: movs r0, #0 |
7 | 2000fec8: lsls r4, r1, #12 |
8 | 2000feca: movs r0, #0 |
9 | 2000fecc: lsls r0, r0, #1 |
10 | 2000fece: movs r0, r1 |
11 | 2000fed0: strh r0, [r0, #0] |
12 | 2000fed2: strh r2, [r0, #32] |
13 | 2000fed4: lsrs r0, r0, #4 |
14 | 2000fed6: str r0, [r0, r0] |
15 | 2000fed8: movs r1, r0 |
16 | 2000feda: movs r0, r0 |
17 | 2000fedc: vhadd.u8 d2, d0, d0 |
Ich bin zuwenig bewandert im Thumb code um zu erkennen, was hier eventuell zum problem führt. Ich vermute mal eine addition.
:
Bearbeitet durch User
> Ich vermute mal eine addition.
Anstatt Dich wilden, unfundierten Spekulationen hinzugeben, solltest Du
Dich lieber an die Dok halten.
Warum NOCHMAL der Stack disassembliert?
Da stehen DATEN (z.B. Rücksprungadressen, die in diesem Zusammenhang
interessant sein könnten), kein CODE!
Lies' bitte das erwähnte DDI0403, bevor Du hier nochmal aufkreuzt.
Am besten 2-mal oder mehr.
Angehängte Dateien:
-
Stack.png
26 KB
Beitrag schrieb: > Warum NOCHMAL der Stack disassembliert? Ok ich habs nun verstanden. Ich kann den Stack nicht als code interpretieren, da er keinen enthält. Ist eigentlich logisch. Manchmal sieht man den Wald vor lauter Bäumen nicht. Beitrag schrieb: > Da stehen DATEN (z.B. Rücksprungadressen, die in diesem Zusammenhang > interessant sein könnten), kein CODE! Ich hab den memory Dump mal angehängt. Mein Wissen reicht nicht aus um die Daten zu interpretieren. Ich wäre froh, wenn mir jemand hierbei helfen könnte. Beitrag schrieb: > Lies' bitte das erwähnte DDI0403, bevor Du hier nochmal aufkreuzt. > Am besten 2-mal oder mehr. Dieses Dokument hat 1020 Seiten. Ich würde nicht mehr in annehmbarer Zeit fertig werden. Offenbar kennst du dich mit der Materie besser aus als ich. Deshalb bitte ich dich freundlich, dein Wissen mit mir zu teilen. Ich würde meines ebenso mit dir Teilen, solltest du in der Community um Hilfe bitten. Dass ich gewisse Dinge nicht auf anhieb korrekt interpretiere mag mir verzeiht sein. Wäre für mich alles klar, würde ich hier keinen Thread zu diesem Thema eröffnen. Ich bemühe mich so gut es geht, die aufgezeigten Hilfen zu nutzen und nach bestem Wissen und Gewissen zu handeln.
:
Bearbeitet durch User
Sempfdazugeber schrieb: > http://www.ti.com/lit/pdf/SPMA043.PDF > > "Diagnosing Software Faults ..." > > hat nur 19 Seiten. Danke, schaue ich mir an. Hier noch der richtige Link für die Nachwelt: http://www.ti.com/lit/an/spma043/spma043.pdf
:
Bearbeitet durch User
>Ich hab den memory Dump mal angehängt. Da würde ich mal den Code an den Adressen auf dem Stack, die mit 0x800 beginnen genauer, untersuchen. Vermutlich wurde die Exception an der Adresse 0x800_4196 (bzw. durch den vorher stehenden Befehl) ausgelöst. 0x800.., weil dort Flash ist, 0x800_4196, weil die Ret Adresse _4197 ist, mit gesetztem Thumb Bit. Und weil der Stack nach unten läuft. >Dieses Dokument hat 1020 Seiten. Ich würde nicht mehr in annehmbarer >Zeit fertig werden. NEIN! Die relevanten Kapitel haben wahrscheinlich weniger als 100 Seiten, ich schaue jetzt nicht nach. Die wirklich relevante Info steht wahrscheinlich auf genau EINER Seite. Das sollte kein Prob sein, die zu finden und das in annehmbarer Zeit. Was glaubst Du, woher diejenigen, die Du hier fragst, Ihre Info haben? Du sagtest ja, Du wolltest lernen, das Problem zu lösen. Deine bisherigen Fragen zielen aber nur darauf ab, das Problem gelöst zu bekommen...
Beitrag schrieb: > Da würde ich mal den Code an den Adressen auf dem Stack, die mit 0x800 > beginnen genauer, untersuchen. Vermutlich wurde die Exception an der > Adresse 0x800_4196 (bzw. durch den vorher stehenden Befehl) ausgelöst. > 0x800.., weil dort Flash ist, 0x800_4196, weil die Ret Adresse _4197 > ist, mit gesetztem Thumb Bit. > Und weil der Stack nach unten läuft. Genial!!! Das war die Lösung. Beitrag schrieb: > Was glaubst Du, woher diejenigen, die Du hier fragst, Ihre Info haben? > Du sagtest ja, Du wolltest lernen, das Problem zu lösen. Deine > bisherigen Fragen zielen aber nur darauf ab, das Problem gelöst zu > bekommen... Unterschiedlich. Ich persönlich lerne am besten durch Erfahrung. Und dies hier ist eine solche. Ich konnte dank eurer/deiner Hilfe nun die stelle ausfindig machen:
1 | static void Get_SerialNum(void) |
2 | {
|
3 | uint32_t deviceserial0, deviceserial1, deviceserial2; |
4 | |
5 | --> deviceserial0 = *(uint32_t*)DEVICE_ID1; |
6 | deviceserial1 = *(uint32_t*)DEVICE_ID2; |
7 | deviceserial2 = *(uint32_t*)DEVICE_ID3; |
8 | ....
|
Die DEVICE_IDs waren falsch:
1 | #define DEVICE_ID1 (0x1FFF7A10)
|
2 | #define DEVICE_ID2 (0x1FFF7A14)
|
3 | #define DEVICE_ID3 (0x1FFF7A18)
|
Er griff also auf eine falsche Addresse zu. Das war die Addresse im reservierten Bereich. So wäre es richtig gewesen:
1 | #define DEVICE_ID1 (0x1FFFF7E8)
|
2 | #define DEVICE_ID2 (0x1FFFF7EA)
|
3 | #define DEVICE_ID3 (0x1FFFF7EC)
|
Vielen Dank! Als kleiner Nebeneffekt, hänge ich hier mal ein funktionierendes VCP Beispiel für den STm32F105 an. Ein solches sucht man nämlich vergeblich im Internet. Vielen Dank nochmals.
Claudio H. schrieb: > static void Get_SerialNum(void) > { > uint32_t deviceserial0, deviceserial1, deviceserial2; > > --> deviceserial0 = *(uint32_t*)DEVICE_ID1; > deviceserial1 = *(uint32_t*)DEVICE_ID2; > deviceserial2 = *(uint32_t*)DEVICE_ID3; > .... > > Die DEVICE_IDs waren falsch: > > #define DEVICE_ID1 (0x1FFF7A10) ...und diese Adresse wird via R3 zugegriffen, was den Trap auslöst. > #define DEVICE_ID2 (0x1FFF7A14) > #define DEVICE_ID3 (0x1FFF7A18) > > Er griff also auf eine falsche Addresse zu. Das war die Addresse im > reservierten Bereich. > > So wäre es richtig gewesen: > > #define DEVICE_ID1 (0x1FFFF7E8) > #define DEVICE_ID2 (0x1FFFF7EA) > #define DEVICE_ID3 (0x1FFFF7EC) Sieht aber immer noch komisch aus, denn nun ist der Abstand zwischen den IDs nicht mehr 4 Bytes sondern nur noch 2. Sollte der Zugriff daher nicht als uint16_t erfolgen?
Johann L. schrieb: > Sieht aber immer noch komisch aus, denn nun ist der Abstand zwischen den > IDs nicht mehr 4 Bytes sondern nur noch 2. Sollte der Zugriff daher > nicht als uint16_t erfolgen? Gute Frage. Da der Code von der ST-Library ist, habe ich das bisher noch nicht näher angeschaut.
Beitrag schrieb: > Und warum ist 0x1FFFF7E8 "richtiger" als 0x1FFF7A10? Weil 0x1FFF7A10 der Speicherort der DeviceID für einen anderen Controller war. 0x1FFFF7E8 ist für den STM32F105 die korrekte Adresse der DeviceID.
:
Bearbeitet durch User
>Und warum ist 0x1FFFF7E8 "richtiger" als 0x1FFF7A10?
Inzwischen nachgeschaut: Das ist die Device ID Sig des Chips
Thread beobachten
Seitenaufteilung abschaltenBitte 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.