Komisches Logiklevel-Phänomen an PORTB

[Harald M. (transporter08)]

Hallo zusammen,

ich habe ein seltsames Phänomen mit einem ATmega32U2.

an PORTB habe ich 3 Pins (PB5, PB6, PB7) auf Eingang geschaltet, die 
anderen auf Ausgang (mittels DDRB = 0x1F).
Auf PB7 habe ich zusätzlich den internen Pullup aktiviert (PORTB = 
0x80).

PB7 ist unbeschaltet.
PB6 ist ueber einen externen Pullup von 4k7 auf VCC geschaltet.
PB5 ist mit dem Y-Ausgang (Pin5) eines HC151 verdrahtet (alle 
MUX-Eingaenge des HC151 sind ebenfalls auf High)

In der Main-Loop lass ich mir ueber den UART den Inhalt von PINB 
ausgeben.

Wenn ich jetzt das Gebilde einschalte, dann wird mir 0xE0 (d.h. PB7, 
PB6, PB5 auf High) als PINB-Inhalt angezeigt (wie erwartet).

Nach 1-2 sekunden wird mir dauerhaft 0x80 angezeigt (d.h. PB6, PB5 
sollen Low sein), obwohl nix verändert wurde.

Wenn ich jetzt mit einem Multimeter an PB5 und PB6 messe, wird mir +5V 
angezeigt ?!?!?!

Lege ich jetzt PB6 (der mit dem externen Pullup) an Masse, bleibt die 
Anzeige auf 0x80, nehme ich den Massepegel weg, dann wird kurzzeitig 
0xC0 angezeigt (d.h. PB7, PB6 auf High, PB5 komischerweise immer noch 
auf Low).

Anschliessend wird nach kurzer Zeit wieder 0x80 angezeigt.

Woher kann der AVR-interne Lowpegel an PB6,PB5 kommen, obwohl von aussen 
an den Pins gemessen, diese auf +5V liegen ?

Kann sich da jemand einen Reim drauf machen ?

Vielen Dank schonmal.

[Oliver (Gast)]

Code?

Oliver

[Harald M. (transporter08)]

Wie gesagt:

int main(void)
{
  UARTInit();

  DDRB  = 0x1F;
  PORTB = 0x80;

  for (;;)
  {
    UARTPrintNL ();
    UARTPrintHex( PINB );
  }
}

[Frank M. (ukw) (Moderator)]

Zeige bitte mal UARTPrintHex().

Sonst probiere mal:

  uint8_t value;
  ...
  value = PINB;
  UARTPrintHex(value);

[Harald M. (transporter08)]

Danke für deinen Hinweis. Hab mal deinen Vorschlag so eingebaut.

Aber am Verhalten und den angezeigten Werten ist keine Änderung.

Aber am UARTPrintHex() liegts nicht.
Eine testweise Ausgabe von verschiedenen Werten klappt einwandfrei.

Code sieht nun so aus:

int main(void)
{
  UARTInit();

  DDRB  = 0x1F;
  PORTB = 0x80;

  for (;;)
  {
    uint8_t pinvalue = PINB;

    UARTPrintNL ();
    UARTPrintHex( pinvalue );
  }
}

[Steffen H. (Gast)]

Bei PORTB klingeln bei mir immer die Alarmglocken wegen JTAG. Ist der 
vieleicht aktiviert?

[Frank M. (ukw) (Moderator)]

Harald Meier schrieb:
> Aber am Verhalten und den angezeigten Werten ist keine Änderung.

Dann kann ich mir das nur noch so erklären, dass Deine externe 
Beschaltung nicht stimmt. Vielleicht hast Du Dich bei den Pins verzählt 
;-)

[spess53 (Gast)]

Hi

>Bei PORTB klingeln bei mir immer die Alarmglocken wegen JTAG. Ist der
>vieleicht aktiviert?

Wenn der ATMega32U2 nun aber gar kein JTAG besitzt. Klingelt es jetzt 
auch noch?

MfG Spess

[Harald M. (transporter08)]

@Steffen H.:

der ATmega32U2 hat kein JTAG.

Alternative Funktionen von
PB5: PCINT5
PB6: PCINT6

(PCINT = Port Change Interrupt, ist aber nicht aktiv)

@Frank M.:

glaube mir bitte, das hab ich schon 20mal geprüft :-)

beide Eingänge reagieren ja kurzeitig auf den angelegten und dann wieder 
entfernten GND-Pegel bis der AVR sich den Low-Pegel aus den Fingern 
saugt.

[Frank M. (ukw) (Moderator)]

Harald Meier schrieb:
> glaube mir bitte, das hab ich schon 20mal geprüft :-)

PB7 bleibt dauerhaft HIGH wegen dem internen Pullup. Das ist unabhängig 
von dem Pinout - und deshalb verhält er sich auch absolut korrekt.

Aber auch PB6 müsste dank dem externen 4,7K Pullup dauerhaft auf High 
bleiben. Da ist doch sonst nichts angeschlossen, oder?

Wenn er nicht auf High bleibt, kommst Du um die 21. Überprüfung (bitte 
durchklingeln) nicht herum ;-)

Wo hast Du mit dem Multimeter gemessen? Direkt am Pin des µCs?

Du könntest PB6 auch mal auf Ausgang schalten und jede Sekunde togglen. 
Da müsste der Pegel dauernd sekündlich wechseln. Wenn nicht, bist Du 
entweder auf dem falschen Pin oder der ATmega ist defekt.

> beide Eingänge reagieren ja kurzeitig auf den angelegten und dann wieder
> entfernten GND-Pegel bis der AVR sich den Low-Pegel aus den Fingern
> saugt.

Die Pegel benachbarter Pins könnten floaten, wenn Du danebenliegst. Um 
das auszuschließen, schalte alle unbenutzten Pins auf Ausgang oder 
Eingang mit aktiviertem Pullup.

[Harald M. (transporter08)]

@ukw:

Danke erstmal für deine Anteilnahme :-)

> PB7 bleibt dauerhaft HIGH wegen dem internen Pullup. Das ist unabhängig
> von dem Pinout - und deshalb verhält er sich auch absolut korrekt.

Ja. Komischerweise ist mit diesem Pin alles in Ordnung.

> Aber auch PB6 müsste dank dem externen 4,7K Pullup dauerhaft auf High
> bleiben. Da ist doch sonst nichts angeschlossen, oder?

Nein, ausser dem Pullup ist dort nix angeschlossen.

> Wenn er nicht auf High bleibt, kommst Du um die 21. Überprüfung (bitte
> durchklingeln) nicht herum ;-)

Habe die 21. Überprüfung mit dem Piepser durchgeführt :-). Leider alles 
wie gehabt :-(

> Wo hast Du mit dem Multimeter gemessen? Direkt am Pin des µCs?

Ja. Direkt an den Pins des ATmegas.

> Du könntest PB6 auch mal auf Ausgang schalten und jede Sekunde togglen.
> Da müsste der Pegel dauernd sekündlich wechseln. Wenn nicht, bist Du
> entweder auf dem falschen Pin oder der ATmega ist defekt.

Gute Idee. Hab ich nun mal ausprobiert. PB6 auf Ausgang und getoggelt. 
Wie gewünscht wechselt der Pegel nun im Takt von PORTB.PB6.

Allerdings ist beim PB5 immer noch alles beim alten.
(sieht Low-Pegel)

[Dosmo (Gast)]

Ich hab ein etwas ähnliches Verhalten mal in einer Schaltung gesehen, wo 
an einem anderen IC die Blockkondensatoren gefehlt haben.
Vielleicht schwingt bei Dir irgendetwas? Hast Du mal den µC getauscht?