struct problem / serielle Schnittstelle

CStoll schrieb:

derTim schrieb:

mehr als einen Pointer auf den Beginn des Arrays zu setzen mache ich noch gar nicht - also ich greife bis jetzt nirgends im code auf die Werte von dem Array zu...

Seltsam - funktioniert denn die Schnittstelle noch, wenn du nur das Array anlegst (ohne den Zeiger)?

PS: Zeig mal bitte etwas zusammenhängenderen Code.

Ja wenn ich den Zeiger weglasse auf das Array, funktioniert die serielle Schnittstelle. Ansonsten wäre es möglich, dass das data segment zu klein ist... aber so...

Ich bekomm auch keinerlei Warnungen oder Fehlermeldungen angezeigt.

Bezüglich Code kann ich nicht alles zeigen: aber wie gesagt zuerst wird eine globale Variable Array vom struct erzeugt und anschließend kommen die C-Funktionen (lokal deklariert)

Innerhalb einer solchen lokalen Funktion wird ein Zeiger auf dieses Struct Array erzeugt. Mehr Code gibt es zu diesem struct Array nicht, weil ich es gerade versuche zu installieren (aber leider nicht ganz so funktioniert)

derTim

CStoll

Sorry, hier hat wohl kaum jemand eine funktionstüchtige Kristallkugel (meine habe ich vor geraumer Zeit entsorgt, weil sie nichts brauchbares angezeigt hat :D) - und aus dieser Beschreibung könnte ich vielleicht etwas zusammenbauen, aber ich weiß nicht ob das Ähnlichkeiten mit deinem Problemprogramm hat. Also entweder du zeigst uns deinen Code oder du wirst wohl alleine nach Fehlern suchen müssen.

(das sollte keine Drohung sein, nur ein Hinweis)

CStoll schrieb:

Sorry, hier hat wohl kaum jemand eine funktionstüchtige Kristallkugel (meine habe ich vor geraumer Zeit entsorgt, weil sie nichts brauchbares angezeigt hat :D) - und aus dieser Beschreibung könnte ich vielleicht etwas zusammenbauen, aber ich weiß nicht ob das Ähnlichkeiten mit deinem Problemprogramm hat. Also entweder du zeigst uns deinen Code oder du wirst wohl alleine nach Fehlern suchen müssen.

(das sollte keine Drohung sein, nur ein Hinweis)

versteh ich auch nicht als Drohung - das ist mir schon klar... Nur am Code liegt es nicht... ich glaube eher, dass eine überschneidung im speicherbereich vorliegt.. hab gerade mal versucht das Array zu initialisieren mit irgendwelchen Werten -> und siehe da, die USART funktioniert ebenfalls nicht mehr... von daher wird hier das DataSegement doch zu klein sein...

Mal schaun wie ich das ändern kann..

derTim

derTim schrieb:

Mal schaun wie ich das ändern kann..

lass den linker ein mapfile generieren und schau mal, wo er die variablen hinpackt bzw. ob sich irgendwas übelappt. allerdings dürfte bei statisch definierten variablen jeder noch so schäbige linker inder lage sein, überlappungen bzw. segmentüberläufe zu erkennen und fehlermeldungen zeigen (vorausgesetzt er kennt die begrenzungen deines controllers, diese angaben solltest du vielleicht auch mal überprüfen).
ist deine serielle schnittstelle vielleicht interruptgesteuert?

Reine Buttermilch schrieb:

derTim schrieb:

Mal schaun wie ich das ändern kann..

lass den linker ein mapfile generieren und schau mal, wo er die variablen hinpackt bzw. ob sich irgendwas übelappt. allerdings dürfte bei statisch definierten variablen jeder noch so schäbige linker inder lage sein, überlappungen bzw. segmentüberläufe zu erkennen und fehlermeldungen zeigen (vorausgesetzt er kennt die begrenzungen deines controllers, diese angaben solltest du vielleicht auch mal überprüfen).
ist deine serielle schnittstelle vielleicht interruptgesteuert?

das array wird in der.bss section installiert; da es ja global definiert wird.

Einen Überlauf sollte der Compiler eigenltich erkennen.

Execution Region ER_ZI (Base: 0x00200054, Size: 0x0000518c, Max: 0xffffffff, ABSOLUTE)

Base Addr Size Type Attr Idx E Section Name Object

0x00200054 0x00001800 Zero RW 101 .bss phy_init.o
0x00201854 0x00003500 Zero RW 125 .bss buf.o
0x00204d54 0x00000004 PAD
0x00204d58 0x00000488 Zero RW 1 STACK rm9200.o

derTim

nein meine schnittstelle ist nicht interrupt-gesteuert.

derTim schrieb:

das array wird in der.bss section installiert; da es ja global definiert wird.

Execution Region ER_ZI (Base: 0x00200054, Size: 0x0000518c, Max: 0xffffffff, ABSOLUTE)

Base Addr Size Type Attr Idx E Section Name Object

0x00200054 0x00001800 Zero RW 101 .bss phy_init.o
0x00201854 0x00003500 Zero RW 125 .bss buf.o
0x00204d54 0x00000004 PAD
0x00204d58 0x00000488 Zero RW 1 STACK rm9200.o

von dem array ist nix zu sehen, oder ist eines der beiden objekte im .bss das array? stimmen die einstellungen? beginnt dein RAM wirklich bei 0x00200054 und hört bei 0xffffffff auf? das wären irgendwie 4GB, scheint mir etwas viel zu sein, aber vielleicht missverstehe ich auch diese 'max' angabe. ansonsten: debuggen (single step, adressen, inhalte der variablen anschauen usw.)

über meine serielle schnittstelle bekomm ich grad garnichts mehr angezeigt... so als wenn sie tod wäre... hab auch mal ein ganz einfaches programm ausprobiert - aber nichts....

Weiß gar nicht wie man diese Schnittstelle software-mäßig komplett unbrauchbar machen kann.

derTim

derTim schrieb:

Weiß gar nicht wie man diese Schnittstelle software-mäßig komplett unbrauchbar machen kann.

das ist so gut wie unmöglich. was ist das für ein controller, den du da hast?

ein AT91RM9200 Controller ist das...

derTim schrieb:

ein AT91RM9200 Controller ist das...

ach so, ich kenne mich etwas mit at91sam7's aus. scheint das selbe u(s)art peripheral drauf zu sein. hehe, hab grade gelesen dass der auch kein IIC slave kann, aber egal, zeig doch mal, wie du den usart initialisiert hast.
übrigens: bei atmel-ARMs musste unbedingt die errata-sheets lesen, wegen der vielen hardware-bugs, die die dinger haben.

hab den usart1 genommen

AT91PS_USART COM1 = AT91C_BASE_US1;

	//pmc
	AT91F_PMC_EnablePeriphClock ( AT91C_BASE_PMC, 1<<AT91C_ID_US1 ) ;

	//define RXD and TXD as peripheral 
	AT91F_PIO_CfgPeriph(AT91C_BASE_PIOB,AT91C_PB21_RXD1 | AT91C_PB20_TXD1,0);

	//usart_config
	AT91F_US_Configure (COM1, MCK,AT91C_US_ASYNC_MODE, 115200, 0);

	//enable usart 
	COM1->US_CR = AT91C_US_RXEN | AT91C_US_TXEN;

das ist die ganze initialisierung vom usart1 - hab bis jetzt auch sehr gut funktioniert...

derTim

das sieht so weit auch ganz gut aus. nun zeig doch mal, wie du zeichen sendest...

das problem ist vll die hardware - ein widerstand hat sich auf seinen lötpads verschoben.... leider hab ich keinen schaltplan von diesem board um genau sagen zu können, wozu dieser widerstand da ist - befindet sich in der nähe des externen flash-ICs...

ich hab nämlcih zuvor mal probiert, leds anzuschalten - an gehen sie aber nur ganz kurz und dann sind sie wieder weg... obwohl sie eigentlich die ganze zeit an sein sollten

derTim

derTim schrieb:

an gehen sie aber nur ganz kurz und dann sind sie wieder weg... obwohl sie eigentlich die ganze zeit an sein sollten

kann es sein, dass sich der controller kurz danach resettet? data- oder prefetch- aborts? setz doch mal 'nen breakpoint auf diese sprungvektoren. womit debuggst du überhaupt?

ich arbeite mit der keil umgebung - und es tritt kein data abort oder ähnliches auf - der code läuft munter weiter (allerings funktioniert halt nichts, kein USART, kein Ethernet und die LEDs blinken nur kurz auf)...

software-fehler schließe ich fast schon aus... die PLL ist stabil und läuft..

derTim

okay, aber wenn die LEDs nicht an bleiben, dann ist ja was oberfaul.
guck' dir auch mal das an: http://www.efo.ru/ftp/pub/atmel/_ARM_MCUs_32bit/ARM_Disk/ARM_Disk_July_2006/pdf/errata/at91rm9200_erratasheet.pdf

.............
............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. ............. .............

das errata-sheet kenn ich - aber so einen Fehler kann man gar nicht in ein solches sheet packen - wie gesagt muss ein HArdware-Fehler sein (vll. dieser falsch liegende Widerstand...) weiß zwar nicht welcher Widerstand einen Prozessor gleich mal völlig lahm legt, wenn er open ist - aber mal schaun..

derTim

hast du eine idee was es sein könnte? der widerstand ist es nicht, ist nämlich einfach nur später reingekommen und deshalb so schief drinnen...

welches anzeichen ist es wenn der prozessor nur ganz kurz die pullups deaktiviert und sofort wieder einschaltet? Ist die Wahrscheinlichkeit, dasss durch die Software irgendwas im Prozessor kaputt gegangen ist größer als ein Hardware-Fehler außerhalb des Prozessors?

Ich meine es geht halt gar nichts, was die Peripherie angeht - beide RS232 nicht, die Ethernet Schnittstelle empfängt keine Pakete und die LEds blinken nur einmal ganz kurz auf...

derTim

da gibt es mehrere möglichkeiten. was geht noch?
- kommst du über's JTAG noch drauf?
- wenn ja, was zeigt der debugger an?
- bist du ganz sicher, dass sich der controller nicht wiederholt resettet?
- ist vielleicht der bootloader aktiv? (ich nehme an, dein controller hat sowas)
- wie ist es mit den PLL settings und clocks? ist da alles klar?
- vielleicht hardwarefehler? kalte lötstellen (kannst mit 'nem durchgangsprüfer messen)?
- schwingt der quarz noch (kannst du mit'm oszi sehen).

musste eben systematisch vorgehen und fehlerquellen ausschliessen...

also durch software kann man 'nen µC kaum zerstören, es sei denn, du hast vielleicht irgendwelche security-bits gesetzt, so dass gar nichts mehr geht oder die PLL astronomisch hochgefahren und das teil übertaktet, aber das alles muss schon mit böser absicht geschehen sein.