ATMega328p RX UART Interrupt µC stürzt ab

Marius D. schrieb:
> ISR(USART0_RXC_vect)
> {
>
> }

Hier ist ein Fehler, der andere in Zeile 42.

Ich habe den Fehler wohl so halb gefunden. Das Empfangsbit ist permanent 
auf 1. Also ich empfange andauernd Daten, obwohl nichts!!! gesendet 
wird.

Hat jmd. einen Rat was das sein könnte? Der Chip wird's wohl nicht sein, 
oder?!

Marius D. schrieb:
> .... stürzt der Mikrocontroller ab.

Das ist wie:

Wenn ich losfahre geht das Auto kaputt.

Marius D. schrieb:
> Das Empfangsbit ist permanent
> auf 1.

Und wie wäre es, es in der ISR zu löschen?

Mitlesa schrieb:
> Marius D. schrieb:
>> .... stürzt der Mikrocontroller ab.
>
> Das ist wie:
>
> Wenn ich losfahre geht das Auto kaputt.

Ich habe es jetzt. Wenn ich initialisiere ist es ok.
Sende ich dann einmal Daten, hat er permanenten das Bit an, dass Daten 
empfangen wurden.

Daher meine Frage: Muss man das vll. manuell zurücksetzen?!
Habe schon mal mit ATMega168 gearbeitet, da war das nicht so. Und ich 
dachte das ist der gleiche Chip nur 32kb. Macht das P dort was aus?! Im 
Datenblatt habe ich dazu nichts gesehen!

m.n. schrieb:
> Marius D. schrieb:
>> Das Empfangsbit ist permanent
>> auf 1.
>
> Und wie wäre es, es in der ISR zu löschen?

Welches ist das?

When the Receive Complete Interrupt Enable (RXCIEn) in UCSRnB is set, 
the USART Receive Complete
interrupt will be executed as long as the RXCn Flag is set (provided 
that global interrupts are enabled). When
interrupt-driven data reception is used, the receive complete routine 
must read the received data from UDRn in
order to clear the RXCn Flag, otherwise a new interrupt will occur once 
the interrupt routine terminates.

1 zu 1 aus dem Datasheet

Volker schrieb:
> When the Receive Complete Interrupt Enable (RXCIEn) in UCSRnB is set,
> the USART Receive Complete
> interrupt will be executed as long as the RXCn Flag is set (provided
> that global interrupts are enabled). When
> interrupt-driven data reception is used, the receive complete routine
> must read the received data from UDRn in
> order to clear the RXCn Flag, otherwise a new interrupt will occur once
> the interrupt routine terminates.
>
> 1 zu 1 aus dem Datasheet


Ja ich habe es getestet, auch vorher schon. Das klappt nicht.
Pollen ist das Programm zu Groß, ich verschlucke die Hälfte sonst.
Ich habe sogar in der ISR nochmal das Datenregister (Empfangsbuffer) 
geleert und in UCR0A = 0 gesetzt, also das 7. Bit.


Sobald er in die ISR geht, stürzt er ab. Betreibe ihn übrigends mit 8Mhz 
und 3V3.

Patrick J. schrieb:
> Hi
>
> Marius D. schrieb:
>> Ja ich habe es getestet,
>
> Was ist hier 'es'?
>
> Marius D. schrieb:
>> must read the received data from UDRn in
>> order to clear the RXCn Flag
>
> Du musst nicht das Bit löschen, Du musst die Daten lesen - laut dem
> Auszug.
>
> Aber weder das Eine, noch das Andere ist in Deiner ISR zu finden :)
>
> MfG


Das mache ich dort. Ich habe keine Ahnung warum das nicht geht.
Das war ja auch nur der Body als Auszug.

Ich kann das Bit löschen, die Daten lesen es geht alles nicht.
Der resettet sobald ich den ISR aktiviert habe (sei()).

Könnte auch ganz banal ein Speicherüberlauf sein.

Aber was soll die Raterei? Du solltest schon das ganze Programm zeigen. 
Nicht dass am Ende noch eine Beschwerde kommt, wie würden hier nur alle 
dummes Zeug von uns geben anstatt effektiv zu helfen.

> Wenn Du mehr Daten an Deinen µC verschickst, als dieser verarbeiten
> kann, dann ist entweder die Baudrate zu hoch, der Prozessor zu langsam
> oder einfach das Programm zu umständlich. Ich tippe auf letzteres.
>
>
> Gruß
>
> Jobst

Da tippst du leider falsch. Das Programm ist nicht umständlich. Das ist 
sogar sehr optimiert und läuft tlws (was die WLAN Sachen angeht) auf den 
XMEGA einwandfrei.

Hier habe ich nen Mega genommen, da die sehr kleinen XMega (Xmega32e5) 
einfach zu teuer sind. Und für die großen die dann billiger sind 
(Xmega32a4) ist nicht genug Platz und wäre auch Verschwendung da nur ein 
paar Pinne gebraucht werden.

In der ISR habe ich rein gar nichts gemacht. Ich speichere dort das Byte 
in ein Array wie schon beschreiben:

1

ISR(USART0_RXC_vect)

2

{

3

   buf[i++] = UDR0;

4

5

   if (i > 250) i = 0;

6

}

Die init habt ihr ja, was ist noch relevant?
Ich denke mal so, wenn ich ein Programm habe, was die Sachen NUR drin 
hat (init vom ISR und die ISR, eine while die leer ist) und das hatte 
ich testweise drauf gespielt dann frage ich mich was abgeht.


Pollen geht auch. Ich habe testweise jetzt mal so in regl. Abständen 
eine Abfrage eingebaut die dann zur Get_Uart_Data fkt springt. Das geht 
so, toll finde ich das jedoch nicht.


Achso: Ich habe sogar mal ISR_BLOCK getestet, auch ohne Erfolg.
Ich habe so das leichte Gefühl, das der µC vll. ne Macke hat.

Baud ist 56000 und Watchdog ist mit 2sek. aktiv.

Marius D. schrieb:
> Achso: Ich habe sogar mal ISR_BLOCK getestet, auch ohne Erfolg.

Das verstehe ich nicht, ISR_BLOCK geht doch immer.
Probiere doch mal die Option DISABLE_ERROR. Dann müßte alles fehlerfrei 
laufen.

Marius D. schrieb:
> ISR(USART0_RXC_vect)

Liegt im Widerspruch zu:

Marius D. schrieb:
> ich habe ein Projekt mit einem ATMega328P

Der ATmega162 hat einen USART0_RXC_vect
Beim ATMega328P heißt das Ding: USART_RX_vect

Jobst M. schrieb:
> Wahrscheinlich ehr nicht ...
Sehe ich auch so!
Ich glaube dass der Fehler auf dem OSI-Layer 8 zu suchen ist.

>Pollen geht auch. Ich habe testweise jetzt mal so in regl. Abständen
>eine Abfrage eingebaut die dann zur Get_Uart_Data fkt springt. Das geht
>so, toll finde ich das jedoch nicht.

Also stimmt etwas mit der ISR nicht.
Vielleicht ein falscher ISR-Vektor?

Übersetzt du deinen Code auch wirklich für den 328P?

Volker schrieb:
>>Pollen geht auch. Ich habe testweise jetzt mal so in regl. Abständen
>>eine Abfrage eingebaut die dann zur Get_Uart_Data fkt springt. Das geht
>>so, toll finde ich das jedoch nicht.
>
> Also stimmt etwas mit der ISR nicht.
> Vielleicht ein falscher ISR-Vektor?
>
> Übersetzt du deinen Code auch wirklich für den 328P?

Ja, ist wirklich für den 328P.

Jobst M. schrieb:
> Marius D. schrieb:
>> Da tippst du leider falsch.
>
> Ich denke immernoch, dass ich richtig liege.
Ok. Wie du willst. Ich weiß es besser.

> Marius D. schrieb:
>> In der ISR habe ich rein gar nichts gemacht. Ich speichere dort das Byte
>> in ein Array wie schon beschreiben:
>
> Und Du meinst, dass Du den Quellcode noch immer vor uns verheimlichen
> möchtest, wir Dir aber sagen sollen, wo der Fehler steckt?
> Okay, Du schreibst in der ISR Daten in ein Array. Sonst wird damit
> natürlich nichts gemacht.
Klar. Aber da das nicht funktioniert hat, habe ich das Testprogramm wie 
beschreiben drauf gemacht, um zu gucken ob es vll. an meinem vom XMega 
importiertem Code für WLAN liegt. Testprogramm macht die gleichen Faxen.

> Marius D. schrieb:
>> Ich habe so das leichte Gefühl, das der µC vll. ne Macke hat.
>
> Wahrscheinlich ehr nicht ...
Hoffe ich auch mal. Waren 10x aus China. Die anderen teste ich, sobald 
die Sache läuft, dann baue ich die anderen Teile zusammen.

>
> Gruß
>
> Jobst

Marius D. schrieb:
> Ja, ist wirklich für den 328P.

Meine Arduino IDE sagt dazu:

1

In function 'USART0_RXC_vect':

2

3

E:\Daten\Arduino\Forum\UART328\UART328.ino:2:1: warning: 'USART0_RXC_vect' appears to be a misspelled signal handler, missing __vector prefix [-Wmisspelled-isr]

4

5

 ISR(USART0_RXC_vect)

Dein Compiler sagt das gleiche, du muss ihm nur mal zuhören!

Georg G. schrieb:
> Du musst ein blutiger Anfänger sein.
Ja, so in etwa...

Georg G. schrieb:
> Der Könner schaltet alle Warnungen ab.
Ich bin zu ehrgeizig/stolz, um mit solchen Fragen hier im Forum 
aufzuschlagen.
Wenn die Warnungen mir dabei helfen, dann schalte ich sie ein.

Und wenn das nur was für Weicheier ist, dann bin ich eben ein Weichei.

Arduino F. schrieb:
> Marius D. schrieb:
>> ISR(USART0_RXC_vect)
>
> Liegt im Widerspruch zu:
>
> Marius D. schrieb:
>> ich habe ein Projekt mit einem ATMega328P
>
> Der ATmega162 hat einen USART0_RXC_vect
> Beim ATMega328P heißt das Ding: USART_RX_vect
>
> Jobst M. schrieb:
>> Wahrscheinlich ehr nicht ...
> Sehe ich auch so!
> Ich glaube dass der Fehler auf dem OSI-Layer 8 zu suchen ist.

Jo das war es. Der Vector ohne C und nun geht's.
Habe ich mich verlesen im Datenblatt.

@Marius:

Wie stellst du eigentlich fest ob der MC noch läuft bzw "abgestürzt" 
ist?

Volker schrieb:
> @Marius:
>
> Wie stellst du eigentlich fest ob der MC noch läuft bzw "abgestürzt"
> ist?

Ich habe nach der uart-init (also vor der while(1) ein "START" gesendet 
und dann geguckt.