|
Anzeige
|
Data Abort Exception durch Library
Gast
#367311
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
Gast
#367312
Ich sollte wohl noch erwähnen, dass das Problem nur auftritt, wenn Floating-point Formate benutzt werde.
Gast
#367313
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?
Gast
#367314
Ä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.
Gast
#367316
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
Gast
#367317
Nur zur Klarstellung. GNUARM verabeitet diese Zeile auch ohne Fehler oder Warnungen. Nur während der Abarbeitung geht es schief!
Gast
#367318
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 Antwort schreiben |
Anzeige
|
