atmega324pb: Konflikt Timer2 und USART2?

[Randy B. (rbrecker)]

Hallo zusammen,

mir ist gerade aufgefallen, dass es wohl einen Ressourcenkonflikt 
zwischen TC2 und USART2 beim Mega324PB gibt:

int main() {
    TCCR2A = 0xf3;
    TCCR2B = 0x03;
    OCR2A = 128;
    OCR2B = 128;
    DDRD |= _BV(6) | _BV(7);
    
    UCSR2B = 0x10; // oder 0x08

    while(true);
}

Wird der USART2 eingeschaltet (UCSR2B) stellt OC2A den Betrieb ein. Bei 
OC2B habe ich noch meine Impulse.

Was geht hier vor?

Danke für Hinweise!

[Marc V. (Firma: Vescomp) (logarithmus)]

Randy B. schrieb:
> Was geht hier vor?

 Nix, muss so sein.

 PB.3 ist sowohl TxD1 als auch OC2A.

 P.S.
 Bild anbei.

[Randy B. (rbrecker)]

Marc V. schrieb:
> Randy B. schrieb:
>> Was geht hier vor?
>
>  Nix, muss so sein.
>
>  PB.3 ist sowohl TxD1 als auch OC2A.
>
>  P.S.
>  Bild anbei.

Es geht um den atmega324pb nicht um 328pb!

[Marc V. (Firma: Vescomp) (logarithmus)]

Randy B. schrieb:
> Es geht um den atmega324pb nicht um 328pb!

 Ooops, sorry.

[c-hater (Gast)]

Randy B. schrieb:

> mir ist gerade aufgefallen, dass es wohl einen Ressourcenkonflikt
> zwischen TC2 und USART2 beim Mega324PB gibt:

Nicht "gibt". Nur "kann geben".

> Wird der USART2 eingeschaltet (UCSR2B) stellt OC2A den Betrieb ein. Bei
> OC2B habe ich noch meine Impulse.
>
> Was geht hier vor?
>
> Danke für Hinweise!

Lies' einfach mal das verdammte Datenblatt. Da steht das doch alles 
drinne. Erste Instanz der Lektüre sind die Abschnitte 5. und 6. Und dann 
könnte man auch noch nachlesen, wie man USART2 korrekt initialisiert, 
wenn man keinen synchronen Modus haben will und damit XCK2 unbenutzt 
bleibt...

[Randy B. (rbrecker)]

c-hater schrieb:

> Lies' einfach mal das verdammte Datenblatt. Da steht das doch alles
> drinne. Erste Instanz der Lektüre sind die Abschnitte 5. und 6. Und dann
> könnte man auch noch nachlesen, wie man USART2 korrekt initialisiert,
> wenn man keinen synchronen Modus haben will und damit XCK2 unbenutzt
> bleibt...

Dann erkläre mir doch mal, wo ich in dem obigen Beispiel den synchronen 
Mode eingeschaltet habe! Wenn Du möchtest, gebe ich Dir das asm-Listing, 
damit Du es besser verstehst.

[c-hater (Gast)]

Randy B. schrieb:

> Dann erkläre mir doch mal, wo ich in dem obigen Beispiel den synchronen
> Mode eingeschaltet habe! Wenn Du möchtest, gebe ich Dir das asm-Listing,
> damit Du es besser verstehst.

Es genügt, wenn du für die Intialisierung symbolische Namen verwendest, 
dann versteht man das sofort, egal ob C oder Asm...

[Randy B. (rbrecker)]

c-hater schrieb:
> Randy B. schrieb:
>
>> Dann erkläre mir doch mal, wo ich in dem obigen Beispiel den synchronen
>> Mode eingeschaltet habe! Wenn Du möchtest, gebe ich Dir das asm-Listing,
>> damit Du es besser verstehst.
>
> Es genügt, wenn du für die Intialisierung symbolische Namen verwendest,
> dann versteht man das sofort, egal ob C oder Asm...

Dann schau Du mal nach, in welchem SFR man denn den synchronen Mode 
aktivieren würde, bevor Du so herummoserst.

[Randy B. (rbrecker)]

Da dieses Verhalten bei TC1 und USART1 (auch ein Pin-Multiplex zwischen 
OC1B und XCK1) so nicht besteht, komme ich zu dem Schluss, dass es ein 
Bug im atmega324pb ist.

[c-hater (Gast)]

Randy B. schrieb:

> Da dieses Verhalten bei TC1 und USART1 (auch ein Pin-Multiplex zwischen
> OC1B und XCK1) so nicht besteht, komme ich zu dem Schluss, dass es ein
> Bug im atmega324pb ist.

Das wäre durchaus denkbar.

Ich habe auch schon den einen oder anderen AVR8-Bug gefunden, der nicht 
im DB unter den Errata gelistet war. Allerdings noch nie einen derart 
gravierenden. Meistens nur Zeug im (sowieso eher lausig dokumentierten) 
Analogkram.

Aber ich würde an deiner Stelle die Hoffnung noch nicht völlig aufgeben. 
Es bleiben nämlich noch Freiheitsgrade. So z.B. ein Fehler im 
C-Compiler. Den hast du bisher nicht ausgeschlossen. Dazu musst du nur 
dasselbe Programm in Assembler schreiben. Die paar Zeilen werden ja wohl 
kein Problem sein, oder?

Auch möglich: ein Hardware-Bug, der zwar existiert, aber leicht zu 
umgehen ist. Sprich: was passiert eigentlich, wenn du UCSR2C und UCSR2D 
explizit mit den gewünschten Werten initialisierst (also mit denen, die 
sie nach Reset sowieso haben sollte), nachdem du UCSR2A und UCSR2B 
gesetzt hast?

Ach so: wie kommt dein Programm eigentlich auf das Device? Eventuell per 
Bootloader? Dann hast du eine Multiplikation möglicher Bugs des jeweils 
verwendeten C-Compilers und der des jeweils verwendeten Nutzcodes...

Mittels Programmierung in Asm kannst du ganz sicher eine ganze Klasse 
von Fehlern in beiden Störvektoren ausschliessen...

[Randy B. (rbrecker)]

Das asm-Listing hatte ich Dir auch schon angeboten: wolltest Du nicht 
haben. Ich habe es aber kontrolliert und es entspricht dem DB. Auch 
alles andere Vorgschlagene habe ich schon durch. Sonst hätte ich kein 
Ticket bei MicroChip aufgemacht.

[Randy B. (rbrecker)]

Zur Info: es ist lt. Support Microchip ein Bug.

[Randy B. (rbrecker)]

Und es betrifft auch die Kombi XCK1/OC1B. Also zweimal derselbe Bug im 
Chip :-( Das ist echt schade ...