Hallo, ich bekomme ein Data Access Abort Exception innerhalb eine sprintf Aufrufes bei GNUARM . Ich habe die Stelle gefunden, sie liegt innerhalb der Libray. Es ist str r0,[r10,#0x4] wobei r10 gleich 0xC0 ist. Wie bekomme ich raus was ich falsch mache bzw. was zur Behebung zu tun ist? Danke
Ich sollte wohl noch erwähnen, dass das Problem nur auftritt, wenn Floating-point Formate benutzt werde.
Der Formatstring löst manchmal gar seltsame Sachen aus ;-) Sind deine Argumente beim Aufruf der sprintf Funktion korrekt? Sind die benutzen Formatangaben im Formatstring implementiert und passen die restlichen Argumente dazu? Ist der Zielpuffer ausreichend gross?
Ähm, bei Verdacht auf Fehler im GCC oder der Library und/oder zur Steigerung der Anzahl nützlicher und hilfreicher Antworten... Hilft es ein möglichst kleines, aber komplettes Codebeispiel inkl. Makefile zu posten, damit der Fehler bei Dritten ggf. nachvollziehbar wird. Hilft es anzugeben, welche Version des GCC bzw. der Library benutzt wird.
> Wie bekomme ich raus was ich falsch mache
Mit an Sicherheit grenzender Wahrscheinlichkeit suchst
du an der völlig falschen Stelle. Du solltest nicht
innerhalb der Library anfangen zu suchen, sondern bei
deinem Aufruf der sprintf() Funktion.
Was bitte ist hier falsch? .... sprintf (line2," %#5.3f V ",3.2 ); .... (hierbei handelt es sich schon um eine vereinfachte Version, 3.2 ist nur dummy, geht aber auch nicht. line2 ist ausrechend lang) Weiter sprintf Aufrufe davor und danach ohne fp Formatschlüssel funktionieren auch einwandfrei. Ein anderer ARM C-Compiler verabeitet diese Zeile problemlos. Danke
Nur zur Klarstellung. GNUARM verabeitet diese Zeile auch ohne Fehler oder Warnungen. Nur während der Abarbeitung geht es schief!
Um diesen Thread abzuschliessen: Die Problemursache war eine Änderung im Startup-Code , die ICH (mea culpa!) dem roty vorgeschlagen hatte und die das wichtige Symbol end aus der Heap-Verwaltung rausgekickt hat... und u.a. die Funktion sprintf verlässt sich halt auf eine funktionierende Heap-Verwaltung... THX an Martin Thomas für das Finden der üblen Bugursache und den Report im en.mikrocontroller.net Forum Stefan
Bitte 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.