Zu große Daten oder Code

[David L. (leidav)]

Hallo,
ich arbeite noch nicht all zu lang mit den Atmegas und habe deshalb 
manchmal noch Schwierigkeiten damit. Mein Problem ist folgendes:
Ich habe erfolgreich Daten über den Usart (mit FT232RL 9600baud) an den 
PC gesendet. Wenn ich nun aber meinen Code für das ansteuern einer PS/2 
Tastatur hinzu linke, dann kommt am PC unabhängig von dem was ich sende 
nur noch 0xF5 an. Ich rufe momentan keine Funktionen aus meiner 
keyboard.c auf und trotzdem funktioniert der Usart Code nicht mehr! In 
meiner keyboard.c hab ich mehrere große Arrays in denen die Keycodes mit 
den dazu passenden Zeichen gespeichert sind. Die Arrays sind zusammen 
aber nur ~200bytes groß und mein Atmega324a hat insgesamt 2k Ram. Laut 
avr-size sollte auch alles passen. Könnte es aber dennoch sein dass ich 
irgendwas überschreibe? Ich nutze den avr-gcc in Version 4.7.2 unter 
Linux. Hat jemand eine Idee was ich falsch mache?

Grüße David


AVR Memory Usage
----------------
Device: Unknown

Program:    1508 bytes
(.text + .data + .bootloader)

Data:        238 bytes
(.data + .bss + .noinit)

[Wegstaben V. (wegstabenverbuchsler)]

David L. schrieb:
> Hat jemand eine Idee was ich falsch mache?

ja, du hast deinen code nicht mit als Anhang beigefügt.

[David L. (leidav)]

So, hier der Code im Anhang

[Falk B. (falk)]

@  David L. (leidav)

>So, hier der Code im Anhang

Deine selbstgestrickten Verzögerungschleifen funktionieren nicht wenn 
die Optimierung eingeschaltet ist, nutze _delay_ms() vom AVR GCC.

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29

[David L. (leidav)]

Ich hab jetzt  die zwei schleifen in der main durch _delay_ms() ersetzt, 
F_CPU 20000000 definiert und mit -Os compiliert. Geholfen hat das nicht. 
Jetzt werden noch wirrere Zeichen gesendet.

[Falk B. (falk)]

@  David L. (leidav)

>Ich hab jetzt  die zwei schleifen in der main durch _delay_ms() ersetzt,

Code?

>F_CPU 20000000 definiert und mit -Os compiliert. Geholfen hat das nicht.
>Jetzt werden noch wirrere Zeichen gesendet.

[Falk B. (falk)]

Ahhh, sag bitte NICHT, dass du keinen Quarz an deinem AVR hast?

http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART

[David L. (leidav)]

Ja ich habe einen Quarz angeschlossen und die dafür nötigen Fuses 
gesetzt.

[Falk B. (falk)]

Du veranstaltest Kauderwelsch. F_CPU wind nur einmalig in EINEM Herader 
definiert, nicht mehrfach. Dieser Header muss dann halt per include 
eingebunden werden. Und ein bestehendes Macro BAUD auf SERIAL_BAUDRATE 
umzudefinieren bringt auser Arbeit und potentiellen Problemem rein gar 
nichts.

Dennoch erklärt es den Fehler nicht. Und du hast wirklich einen 20 MHz 
Quarz? Blinkt/Schaltet dein Port im 1s Takt? CLK DIV 8 Fuse inaktiv?

[David L. (leidav)]

Ja Ich habe einen 20MHZ Quarz. Wenn ich die Optimierung einschalte dann 
blinkt gar nichts mehr! Ohne Optimierung blinkt es irgendwo im 
Millisekunden Bereich. Es könnte sein dass der Controller abstürzt. 
Leider habe ich gerade kein Oszi um zu sehen wie regelmäßig/unregelmäßig 
die Led blinkt.
Das mit F_CPU ist mir schon klar. Die main dient hier nur als Test um 
den Serial und Keyboard Code zu testen. SERIAL_BAUDRATE verwende ich um 
die Konsistenz der Makros im gesamten Projekt zu bewahren 
(MODULNAME_KONSTANTE). Die Header sollen groß teils unabhängig von der 
Implementierung sein da der Code nicht nur auf avrs laufen soll.

Ich habe für die Fuses diesen http://www.engbedded.com/fusecalc Rechner 
verwendet. Dort und bei avrdude gibt es leider keinen atmega324a zu 
Auswahl deswegen hab ich einfach atmega324p bzw. atmega324pu ausgewählt.
Ich habe folgende Optionen verwendet:
lfuse: 0xff
hfuse: 0xd9

[Falk B. (falk)]

@  David L. (leidav)

>Ja Ich habe einen 20MHZ Quarz. Wenn ich die Optimierung einschalte dann
>blinkt gar nichts mehr!

Ist deine Hardware in Ordung? Saubere Spannung? 100nF an VCC/GND?
Watchdog inaktiv geschaltet per Fuses?

>Auswahl deswegen hab ich einfach atmega324p bzw. atmega324pu ausgewählt.
>Ich habe folgende Optionen verwendet:
>lfuse: 0xff
>hfuse: 0xd9

Sieht OK aus.

[David L. (leidav)]

So, hab mal meine Schaltung hoch geladen. Ich habe bis jetzt eher 
geglaubt dass es sich dabei um ein Speicher/Segmentierungs Problem 
handelt.
Zusätzlich habe ich das Problem, dass der Code oft nach mehrmaligen 
einstecken des usb oder avr-isp Steckers nicht mehr funktioniert 
(gelöscht oder anderes komisches Verhalten). Nachdem ich dann neu 
programmiere und über avr-isp Reset auslöse dann funktioniert es wieder 
wie vorher. Könnte es sein dass sich der avr in den parallel 
Programmiermodus schaltet?

[Falk B. (falk)]

@  David L. (leidav)

>geglaubt dass es sich dabei um ein Speicher/Segmentierungs Problem
>handelt.

Man sollte erstmal von einfachen Ursachen ausgehen, siehe 
Fehlersuche.

>Zusätzlich habe ich das Problem, dass der Code oft nach mehrmaligen
>einstecken des usb oder avr-isp Steckers nicht mehr funktioniert

Warum tust du das? beim Entwickeln bleibt der Programmieradapter 
praktisch immer gesteckt.

>(gelöscht oder anderes komisches Verhalten). Nachdem ich dann neu
>programmiere und über avr-isp Reset auslöse dann funktioniert es wieder
>wie vorher.

Dann hast du möglicherweise ein Resetproblem.

> Könnte es sein dass sich der avr in den parallel
> Programmiermodus schaltet?

Nein.

In deinem Schaltplan ist ein 18,432 MHz Quarz eingezeichnet. Was ist 
denn nun WIRKLICH bestückt? Ansonsten sieht der Schaltplan OK aus.
Schalte auch mal den Brown Out Detektor ein mit 4,x V.

[David L. (leidav)]

Ich habe die Platine momentan mit 2x 20Mhz bestückt da Farnell mir den 
anderen Quarz nicht rechtzeitig liefern konnte.
Mit mehr mal ein/aus stecken meinte ich das die Platine nicht mehr 
funktioniert wenn ich sie z.b einen Tag später wieder verwenden möchte 
und neu anstecke. Ich werde jetzt mal die Brown Out Detektion probieren.

[David L. (leidav)]

Wenn ich die beiden Arrays durch uninitialisierte Arrays mit ungefähr 
der selben Größe ersetze, dann funktioniert der Uart wieder. An was 
könnte das liegen?

struct Key shifted_char_de[50];
struct Key unshifted_char_de[50];
struct Key altgr_char_de[10];

[Falk B. (falk)]

An den Arrays sollte es nicht liegen, solange der Speicher ausreichend 
groß ist. Ich vermute ein Problem in deiner Toolchain und dem makefile. 
Im Anhang das HEX-File aus dem guten, alten AVR-Studio. Schau mal ob es 
geht.

[David L. (leidav)]

Danke für das hex-file. Es liegt anscheinend wirklich am Makefile oder 
meiner Toolchain. Deine Version funktioniert so wie sie soll!

[Falk B. (falk)]

Mit Windows wär das nicht passiert ;-)

[Malte S. (maltest)]

Das ruft Erinnerungen wach, als ich mal eine Toolchain mit zu 
generischem Startcode hatte. Die hat stillschweigend Adressen mod 4k 
angesprungen, was nur zum Tragen kam, wenn z.B. durch "zu große" 
initialisiert Daten eine Jumptable zu weit hinten landete. Verwendet du 
zufällig eine crossdev-toolchain unter Gentoo? Dann upgrade mal crossdev 
auf unstable und bau die AVR-tc von Grund auf neu.

[David L. (leidav)]

Ich verwende die Pakete
community/avr-gcc 4.7.2-1
community/avr-libc 1.8.0-4
community/avr-binutils 2.23-2
unter Archlinux

Leider hab ich das Problem immer noch nicht in den Griff bekommen.

[Hmm (Gast)]

>Mit Windows wär das nicht passiert ;-)

Grrrr. Wau! wau! Schnapp! :-)

[David L. (leidav)]

Eigentlich müsste mein Makefile doch funktionieren?

PROGNAME=prog
MMCU=atmega324a
FORMAT=ihex
PROGRAMMER=stk500v2
PART=m324a
PORT=/dev/ttyACM0
PROGCLK=10

CC=avr-gcc
OBJCOPY=avr-objcopy

AVRDUDE_PARAMS= -B $(PROGCLK) -c $(PROGRAMMER) -p $(PART) -P $(PORT)
CFLAGS= -mmcu=$(MMCU) -std=gnu99 -Os -Wall
LDFLAGS=
OBJ= main.o serial.o keyboard.o

all: $(PROGNAME).hex

clean: 
  rm $(PROGNAME).hex $(PROGNAME) $(OBJ)

programm:
  avrdude $(AVRDUDE_PARAMS) -U flash:w:$(PROGNAME).hex
fuse:
  avrdude $(AVRDUDE_PARAMS) -U lfuse:w:0xff:m -U hfuse:w:0xd9:m -U efuse:w:0xfc:m 

$(PROGNAME).hex:  $(PROGNAME)
  #$(OBJCOPY) -j .text -j .data -O $(FORMAT) $(PROGNAME) $(PROGNAME).hex
  $(OBJCOPY) -O $(FORMAT) $(PROGNAME) $(PROGNAME).hex

$(PROGNAME): $(OBJ)
  $(CC) $(LDFLAGS) -o $(PROGNAME) $(OBJ)

%.o : %.c
  $(CC) $(CFLAGS) -c $<