USB Mass Storage Code

Gast #434100
Lesenswert?

Hallo, ich ärgere mich auch schon einige Tage
mit dem IAR-Code rum und bin auch schon
auf ca. 150 Fehlermeldungen beim Compiler runter,
wobei die letzten Fehler sich hartnäckig halten ...
Hast Du's scon geschafft mit dem umpfriemeln?
Hat es überhaupt noch sinn in der Rinchtung
weiterzubasteln oder doch hinwerfen und selber
was zusammenwursteln? ... Bitte bau mich auf
und Antworte das Du's geschafft hast :)
Gast #434171
Lesenswert?

Habe einige "Uebung" im Portieren von code fuer AT91 und AVR von IAR 
nach GNU/gcc und koennte wahrscheinlich auch diesen Code portieren oder 
zumindest helfen. Aber es bringt nichts, denn man darf den Quellcode 
nicht weitergeben. Der gcc-Port laege also nur hier rum und waere keine 
Hilfe. Daher auch bisher nicht der Lizenz unterworfen, Source-code nicht 
hier, da USB Mass-Storage noch nicht gebraucht.

Besser helfen koennte man bei der Portierung des Mass-Storage-Codes von 
Keil. Da kann man wenigstens den Quellcode weiterreichen. Aber die 
Lizenz ist ebenfalls restriktiv: nutzen ("use") darf man den Code nur 
mit Lizenz eines Keil ARM-Entwicklungstoos: "This software may only be 
used under the terms of a valid, current, end user licence from KEIL for 
a compatible version of KEIL software development tools. Nothing else 
gives you the right to use it."

Es gibt "irgendwo" einen freien Mass-Storage Code fuer LPC2000 mit gcc. 
Portierung duerfte aber schwieriger sein, da USB-Hardware zwar aehnlich 
aber USB "Macrocell" bei LPC200 und AT91 meines Wissens unterschiedlich.

Wie auch immer. Schliesse mich Joerg an: Fehlermeldungen hier "pasten", 
vielleicht kann man anhand der Meldungen schrittweise weiterhelfen.
Gast #436060
Lesenswert?

Ich habs geschafft, den code fehlerfrei zu compilieren. Leider 
funktioniert er aber nicht -> dauernd data/prefetch aborts.
ich habe bemerkt, dass malloc nicht funktioniert?!? könnte das der grund 
sein?
(habe malloc durch statische speicherzuteilung ersetzt -> kein erfolg)
Gast #436361
Lesenswert?

Um dabei weiterhelfen zu koennen, muesste man das Linker-Skript 
(Memory-Layout insbes. Position von "Heap-Start",ueblicherweise per 
provide end), den Startup-Code (wg. moegl. Ueberschneidungen von 
data/bss/stacks und heap) und den Quellcode von sbrk 
(Hardware-Interface/syscall fuer malloc) einsehen. Data-Abort "riecht" 
dannach, dass end (oder wie auch immer genannt) auf eine 
Speicheraddresse zeigt, bei der es kein RAM gibt.

Martin Thomas
Gast #436499
Lesenswert?

Ich hab die drei Files mal angehängt.
Noch zu sagen ist, dass ich noch keine Funktionen ins RAM kopiere 
(__ramfunc auskommentiert). Wenn ichs mache, funktioniert noch weniger.

Auf welcher Adresse sollte denn der Heap-Start sein?
Gast #436585
Lesenswert?

Heap-Start ("end") ist lt. dem Linker-script 1000bytes nach RAM_TOP, das 
kann nichts werden, daher auch die data abort exeception. PROVIDE (end = 
.); verschieben direkt nach _end = .; . RAM length und STACK origin 
nochmal pruefen, sieht etwas seltsam aus, das . += 1000 noch seltsamer. 
Linker-Skript ist fuer gcc4-feature "unused code removal" nicht 
geeignet.
#436726
Lesenswert?

Also ich hab das . += 1000 entfernt und die memoryaufteilung 
folgendermassen gemacht:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x00100000, LENGTH = 0x00010000
  DATA (rw)  : ORIGIN = 0x00200000, LENGTH = 0x00004000
  STACK (rw) : ORIGIN = 0x00204000, LENGTH = 0x00000000
}

Laut Konsole (Auszug aus Eclipse) sollte sich alles in einem gültigen 
Adressberiech befinden:

002010e0 B usbms_request_sense_data
002010f4 B DBG_EVT
002010f8 A _bss_end_
002010f8 A _end
002010f8 A end
00204000 N Top_Stack

Das Problem vom Data Abort bleibt aber bestehen. Was meinst du mit
"Linker-Skript ist fuer gcc4-feature "unused code removal" nicht
geeignet"?

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren