ARM softcore cortex M0 : MULS Problem mit gcc

Gast #4875438
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ß
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Gast
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 Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 9 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.