Forum: Mikrocontroller und Digitale Elektronik ARM softcore cortex M0 : MULS Problem mit gcc


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von student (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich simuliere hier gerade den cortex M0 Softcore als Uni-edition und 
sehe da ein Problem mit dem MULS Befehl bei mir.

In Abhängigkeit von den Operanden wird diese mal korrekt ausgeführt, mal 
fängt der cm0 core beim MULS Befehl an, einfach den memory 
durchzuscannen (immer mit dem Faktor 2 steigend bei der HADDR).

Da er dann irgendwann in einen Bereich kommt, wo niemand mehr zuständig 
ist für die Erzeugung des entsprechenden HREADY Signals, wartet er dann 
irgendwann unendlich auf dieses Signal.

Habt ihr so etwas schon einmal gehabt ? Wenn ja wie habt ihr das gelöst?

Workaround wäre ja einfach ein dummy HREADY für jetzt nicht belegte 
Bereiche zu erzeugen (nach einer gewissen Zeit), ist aber sicherlich 
nicht die Lösung dafür oder ?

Gruß

von Jim M. (turboj)


Bewertung
2 lesenswert
nicht lesenswert
student schrieb:
> In Abhängigkeit von den Operanden wird diese mal korrekt ausgeführt, mal
> fängt der cm0 core beim MULS Befehl an, einfach den memory
> durchzuscannen (immer mit dem Faktor 2 steigend bei der HADDR).

Implementiere mal einen Hardfault_Handler(). MULS ist nur für R0-R7 
spezifiziert, alles andere gibt einen Fault.

Eigentlich müsste er in den Lockup gehen, wenn HardFault nicht tut / 
implementiert ist. Vielleicht tut das einfach nur nicht.

Die 16-Bit Fetch klingen etwas nach Instruktion Fetch, aber eigentlich 
sollten die 32-bittig gepipelined sein.

student schrieb:
> Da er dann irgendwann in einen Bereich kommt, wo niemand mehr zuständig
> ist für die Erzeugung des entsprechenden HREADY Signals, wartet er dann
> irgendwann unendlich auf dieses Signal.

Das ist IMHO ein Fehler, den man im Design abfangen sollte. Bei Buffer 
Overflows kommen schon mal Zugriffe auf zufällige Adressen vor - dann 
sollte der sich nicht aufhängen.

von student (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Jim,

danke für Deine Hilfe.
Habe meinen Fehler in der Simu gefunden.

Die Studenten-Version des CM0 hat nur die small Mult unit (also 
sequentiell) drin. Während der Multiplikation zeigt er die 
Zwischenergebnisse auf dem HADDR (was ich als scannen des Speichers 
falsch interpretiert habe), markiert aber korrekt den AHB via HTRANS als 
IDLE.

Das habe ich nicht beachtet. Der CM0 schaut trotzdem auf HREADY ob nicht 
eine Komponente in verzögern will.

Da bei meiner Simu keine Komponente dieses tun soll/möchte,  muss ich 
nur ein dummy HREADY für den Fall von HTRANS=idle erzeugen.

Jetzt muss ich mir nur noch nach eine elegante kleine Lösung für den 
Fall eines echten Buffer Overflows einfallen lassen.

Gruß

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.