Segger Embedded Studio STM32Fxxx_Vectors.s

[temp (Gast)]

Ich arbeite seit längeren mit Crossworks und habe jetzt ein paar Sachen 
zum Testen auch zu Segger Embedded Studio portiert. Sollte ja kein 
Problem sein, die Basis der IDE ist ja die gleiche. Trotzdem weit 
gefehlt. Irgendwie sehen die STM32Fxxx_Vectors.s Dateien komplett anders 
aus als bei Crossworks. Dabei meine ich nicht den Aufbau sondern den 
Namen der Interrupts. Bei Crossworks entsprechen sie dem Namen der in 
den Headerfiles des Controllers definierten IRQn. Z.b. beim STM32F103xB:
USB_HP_CAN1_TX_IRQn und USB_HP_CAN1_TX_IRQHandler.
So sollte es meiner Meinung nach auch sein.

Die Jungs von Segger sind der Meinung, dass das aber CAN1_TX_IRQHandler 
heißen soll und somit anders als der Name für die IRQ-Nummer. Diesen 
Kauderwelsch findet man bei allen drei von mir untersuchten Typen: 
STM32F334K8, STM32F042K6 und STM32F103RB. Es sind auch teilweise 
Interrupts in der Tabelle für die der Controller keine Hardware hat als 
auch umgekehrt.

Hier liest ja immer mal einer von Segger mit. Ist das so wirklich 
beabsichtigt oder hat die künstliche oder humane Intelligenz beim 
Erzeugen der Dateien Mist gebaut?

Auf alle Fälle ein Stolperstein der zu beachten oder auszumerzen ist.

[Erich (Gast)]

temp schrieb:
> Die Jungs von Segger sind der Meinung

Hast du dort schonmal angerufen?

[temp (Gast)]

Für die No commercial Variante werde ich wohl keinen Telefonsupport 
erhalten.
Brauche ich auch nicht, da ich mir selber helfen kann.

Ich habe sie per Mail darauf aufmerksam gemacht. Jedenfalls für den 
STM32F334K8. Dass sich das bei anderen STM32 Controllern wiederholt habe 
ich erst danach festgestellt.

[W.S. (Gast)]

temp schrieb:
> Ist das so wirklich
> beabsichtigt oder hat die künstliche oder humane Intelligenz beim
> Erzeugen der Dateien Mist gebaut?

Stell dir vor, du hättest mit Segger angefangen und dann bei Crossworks 
das Staunen gekriegt. Eben umgekehrt.

Tja, bei all sowas kochen alle Hersteller eben ihr eigenes Süppchen. 
Damit muss man rechnen, alles andere wäre blauäugig.

Vielleicht verstehst du jetzt, warum unsereiner keine IDE benutzt und 
sich Startup, xyz_prozessor.h und Konfiguration selber macht. Da weiß 
man, was man hat.

W.S.

[temp (Gast)]

W.S. schrieb:
> Stell dir vor, du hättest mit Segger angefangen und dann bei Crossworks
> das Staunen gekriegt. Eben umgekehrt.
>
> Tja, bei all sowas kochen alle Hersteller eben ihr eigenes Süppchen.
> Damit muss man rechnen, alles andere wäre blauäugig.
>

Das ist Blödsinn. Ich habe auch eine Antwort von Segger erhalten, die 
den Fehler bestätigt. Wie die Interrupts heißen bestimmt in erster Linie 
der Hersteller der CPU, auch wenn es auch anders gehen würde. Es werden 
die normalen Header von ST eingebunden. In meinem Fall stm32f334x8.h. Da 
stehen auch die symbolischen Namen für die Interrupts z.B. CAN_RX0_IRQn. 
Jede IDE hält sich an diese Konvention und benennt die Interrupts so wie 
in diesem Header vorgegeben. Auch du wirst in deinem Startup die 
Vectortabelle so aufgebaut haben. Bei der Version von Segger steht da 
aber USB_LP_CAN_RX0_IRQHandler obwohl der Chip überhaupt kein USB hat.
Man muss also mit CAN_RX0_IRQn und USB_LP_CAN_RX0_IRQHandler arbeiten 
und das ist die Diskrepanz.

Hier haben die Tools, die aus den CMSIS Packs der Hersteller die Dateien 
generieren sicherlich was durcheinander gewürfelt.

> Vielleicht verstehst du jetzt, warum unsereiner keine IDE benutzt und
> sich Startup, xyz_prozessor.h und Konfiguration selber macht. Da weiß
> man, was man hat.

Das kann ich gut verstehen und ich habe zu allen meinen Projekten auch 
ein makefile und eigenen Startup um sie mit den gnu arm toolchain von 
Arm zu übersetzen. Aber ich verwende alternativ die IDE als Debugger. 
Ich diskutiere auch nicht mit dir über deine und meine Vorlieben. Ich 
meckere auch nicht sondern teile nur meine Erkenntnisse mit, damit 
andere nicht in eine ähnliche Falle tappen.

[Til S. (Firma: SEGGER) (til_s)]

Danke für den Hinweis! Würde ich auch so sehen, entweder Fehler bei uns 
zwischen Stuhl und Keyboard oder der Fehler war schon in den CMSIS 
Dateien, aus denen wir unserer Dateien generieren, enthalten. Beides 
schon erlebt ;-).