HILFE Seltsames Verhalten Atmega 328P auf Arduino-Board mag Code nicht

[Aloysius P. (Firma: FBI) (a_pendergast)]

Vorweg es geht nicht um eine Arduino spezifische Frage/Problem.

Ich habe ein seltsames Problem, das mich seit Tagen beschäftigt und 
wobei ich nahe an der Verzweiflung bin, weil ich keine Lösung finde.

Eigentlich dürfte es das Problem gar nicht geben.


Hintergrund
Ich benutze häufig als HW im Einsatz für bestimmte Projekte 
Arduino-Boards. In der Regel Arduino Nano. Es erspart mir die Erstellung 
eigener PCB’s. Ich stecke sie, die Nanos, auf eigene Schield’s. Die 
Arduino-Boards werden nicht mit der Arduino-IDE oder Arduino Librarys 
programmiert. Der Bootloader ist entfernt und die Fuses sind 
entsprechend eines „normalen“ Atmegas gesetzt. Also das Arduino-Board 
dient lediglich als HW-Platform.

Die Entwicklung und Testung des Codes wird auf einem SDK600 
durchgeführt. Als IDE  dienst AVR Studio 7. Funktiniert alles wird dann 
in der Regel via ISP mittels AVRONE! Oder Atmel-ICE auf das 
Arduino-Board geflasht. Und anschließend die Peripherie unter Beachtung 
der Arduino eigenen PORT Nomenklatur angeschlossen. So weit so gut und 
das hat bisher immer und ausschließlich zu 100% Funktioniert.

Dieses Vorgehen soll hier bitte nicht Gegenstand einer Diskussion 
werden.



Zum aktuellen Problem:

Eine eigene Routine zum ansteuern LDC HD44780 im Mix aus Assembler und 
C, Core Routinen hauptsächlich in Assembler. Auch dieses Vorgehen soll 
bitte kein Diskussionsgegenstand werden, denn es ist unerheblich für das 
Problem. Es wird der 4-Bit Modus verwendet. Dafür werden die unteren 4 
Bits des PORTC (PC0 – PC3) verwendet. RS liegt auf PC4, EN auf PC4. RW 
wird über PB0 angesteuert.

Im  Entwicklungssetting,  Atmega 328P auf SDK600 läuft die LCD 
Ansteuerung auf diversen LCDHD44780 problemlos.


Wird nun der Code auf ein Arduino-Nano Board geflasht. Ich habe 5 
Verschiedene Probiert. Bei allen bleibt das LCD ohne Ausgabe. Auch bei 
einem Arduino Uno. Besonderheit: Drückt man wie wild mehrere male 
hintereinander den Reset-Button... erscheint gelegentlich mal ein oder 
mehrere Buchstaben der zu erwartenden Ausgabe Zeile „Hello World“. Hört 
sich nach Wackelkontakt an. Ist aber ausgeschlossen.


Flashe ich aber nun mit der Arduino IDE und der Arduino eigenen LCD 
Bibliothek ein „Hello World“, was die selben Ports und Port-Bits 
verwendet so funktioniert das einwandfrei. Damit sollte ein eh schon 
unwahrscheinlicher HW Fehler eigentlich ausgeschlossen sein. Und alles 
schreit nach SW Fehler. Also das unangenehmere. Aber wie ließe sich ein 
SW-Fehler annehmen, wenn auf dem Setting Atmega328P auf dem SDK600 der 
LCD Treiber problemlos läuft???

Ich bin leider mit meinem Latein am Ende. Aber ich bin auch nicht 
besonders Klug.


Ist vielleicht jemand pfiffiger als ich und hat eine Idee was dieses 
Phänomen begründen könnte.


Vielen Dank,
Thomas

[Einer K. (Gast)]

Schaltplan geheim.
Programm geheim.
Fuses geheim.

Also:
Du hast mein volles Mitgefühl!
Aber helfen kann ich dir so nicht.

[Philipp K. (philipp_k59)]

Aloysius P. schrieb:
> Wird nun der Code auf ein Arduino-Nano Board geflasht. Ich habe 5
> Verschiedene Probiert.

Weil es nur PC4,PC5 und PC6 auf den Headern des Nanos gibt?

(Text ist mir zu lang um alles zu lesen)

[Christian S. (roehrenvorheizer)]

Unterschiedliches Reset-Verhalten auf beiden boards? Was passiert, wenn 
das LCD langsamer angesteuert wird?

MfG

[Einer K. (Gast)]

Philipp K. schrieb:
> Text ist mir zu lang

Nicht nur lang, sondern auch verwunderlich

Aloysius P. schrieb:
> RS liegt auf PC4, EN auf PC4.

[Old P. (Gast)]

Sowas ähnliches hatte ich letzte Woche auch, Ursache war letztlich ein 
defekter Atmega auf dem Arduino. Das Ding war neu "out of Tüte" und zu 
allem Übel hatte ich den eingelötet, nicht gesteckt. Also wieder 
rausgefummelt, Buchsen rein und der Nächste bitte. Damit und allen 
anderen (hatte 10 geordert) ging es dann wie gewünscht.

Gestern dann mit einem nackten Atmega328 (TQFP) (nix Arduino) auch nur 
Ärger, der Programmer sagt immer "kein Target" (oder so). Jede Leitung 
mehrfach durchgeklingelt, Spannungen gemessen, Quarz überprüft, alles 
bestens, doch die Gurke will nicht.
Heute abend löte ich mal einen neuen auf, auch aus der Reicheltlieferung 
(ich ahne Böses)
Ich muss mir mal einen der teuren Adapter beschaffen.

Old-Papa

[Christian S. (roehrenvorheizer)]

Hallo,

vor Jahren mal bekam ich von Reichelt zwei angeschossene Mega88 
geliefert. Beim Programmieren reagierten sie noch ein  Stück weit, bis 
nichts mehr ging. Die Elektrostatik läßt grüßen.

MfG

[Old P. (Gast)]

Christian S. schrieb:
> Hallo,
>
> vor Jahren mal bekam ich von Reichelt zwei angeschossene Mega88
> geliefert. Beim Programmieren reagierten sie noch ein  Stück weit, bis
> nichts mehr ging. Die Elektrostatik läßt grüßen.
>
> MfG

Nun, ich hätte stutzig werden sollen.... Die haben 328er für 1,94 im 
Programm, aber auch einen gleichen ("Gurtware") für 1,51. Davon hatte 
ich wieder 10 geordert, eben den 2. getestet, "Kann Zielchip nicht 
erreichen". Wahrscheinlich mal wieder ein Griff ins "Reichelt-Klo"

Old-Papa

[Oliver S. (oliverso)]

Was ist denn auf den Nanos für ein Prozessor drauf?

Oliver

[Einer K. (Gast)]

Oliver S. schrieb:
> Was ist denn auf den Nanos für ein Prozessor drauf?

Original: ATMega328P
Gibt aber auch welche/Nachbauten mit MD-328D(und Vorgänger davon)

[Aloysius P. (Firma: FBI) (a_pendergast)]

Old P. schrieb:
> Sowas ähnliches hatte ich letzte Woche auch, Ursache war letztlich ein
> defekter Atmega auf dem Arduino. Das Ding war neu "out of Tüte" und zu
> allem Übel hatte ich den eingelötet, nicht gesteckt. Also wieder
> rausgefummelt, Buchsen rein und der Nächste bitte. Damit und allen
> anderen (hatte 10 geordert) ging es dann wie gewünscht.
>
> Gestern dann mit einem nackten Atmega328 (TQFP) (nix Arduino) auch nur
> Ärger, der Programmer sagt immer "kein Target" (oder so). Jede Leitung
> mehrfach durchgeklingelt, Spannungen gemessen, Quarz überprüft, alles
> bestens, doch die Gurke will nicht.
> Heute abend löte ich mal einen neuen auf, auch aus der Reicheltlieferung
> (ich ahne Böses)
> Ich muss mir mal einen der teuren Adapter beschaffen.
>
> Old-Papa

Hallo und danke!

Nein HW kann es nicht sein, denn: Über Arduino IDE unter benutzung der 
selben Ports läuft alles. Und ins. 6 Boards getestet.

Thomas

[Veit D. (devil-elec)]

Oliver S. schrieb:
> Was ist denn auf den Nanos für ein Prozessor drauf?
ATmega328P.

Vielleicht ja auch sein Eigenbau Shield defekt. Leiterbahn gerissen, 
kalte Lötstelle etc.

Ich hoffe das ist nur hier ein Schreibfehler.
> Dafür werden die unteren 4 Bits des PORTC (PC0 – PC3) verwendet. RS liegt
> auf PC4, EN auf PC4. RW wird über PB0 angesteuert.

[Veit D. (devil-elec)]

Aloysius P. schrieb:

> Nein HW kann es nicht sein, denn: Über Arduino IDE unter benutzung der
> selben Ports läuft alles. Und ins. 6 Boards getestet.

Na dann kann es doch nur an deiner eigenen Software liegen.
Vielleicht ist ja nur die Initialisierung vom Display leicht fehlerhaft. 
Timing o.ä. Mehr gibt die Glaskugel nicht her.

[Aloysius P. (Firma: FBI) (a_pendergast)]

Arduino Fanboy D. schrieb:
> Oliver S. schrieb:
>> Was ist denn auf den Nanos für ein Prozessor drauf?
>
> Original: ATMega328P
> Gibt aber auch welche/Nachbauten mit MD-328D(und Vorgänger davon)

328P original selbe wie im SDK600 steckt

[Aloysius P. (Firma: FBI) (a_pendergast)]

Veit D. schrieb:
> Aloysius P. schrieb:
>
>> Nein HW kann es nicht sein, denn: Über Arduino IDE unter benutzung der
>> selben Ports läuft alles. Und ins. 6 Boards getestet.
>
> Na dann kann es doch nur an deiner eigenen Software liegen.
> Vielleicht ist ja nur die Initialisierung vom Display leicht fehlerhaft.
> Timing o.ä. Mehr gibt die Glaskugel nicht her.

Hab ich mir natürlich auch gedacht, denn meist ist es das ja. Aber warum 
läuft die Fehlerhafte SW im SDK600 auf diversen Atmegas...

aber ich werde die timings noch mal durchgehen...

[Aloysius P. (Firma: FBI) (a_pendergast)]

Veit D. schrieb:
> Oliver S. schrieb:
>> Was ist denn auf den Nanos für ein Prozessor drauf?
> ATmega328P.
>
> Vielleicht ja auch sein Eigenbau Shield defekt. Leiterbahn gerissen,
> kalte Lötstelle etc.
>
> Ich hoffe das ist nur hier ein Schreibfehler.
>> Dafür werden die unteren 4 Bits des PORTC (PC0 – PC3) verwendet. RS liegt
>> auf PC4, EN auf PC4. RW wird über PB0 angesteuert.

Ist kein Eigenbau im Einsatz... LCD direct am Board

[Aloysius P. (Firma: FBI) (a_pendergast)]

Arduino Fanboy D. schrieb:
> Philipp K. schrieb:
>> Text ist mir zu lang
>
> Nicht nur lang, sondern auch verwunderlich
>
> Aloysius P. schrieb:
>> RS liegt auf PC4, EN auf PC4.

Tipfehler!

(RS = Register select) <-> PORTC PortBit 4
(EN = Enable)          <-> PORTC PortBit 5

[Aloysius P. (Firma: FBI) (a_pendergast)]

Invisible Man schrieb im Beitrag #6342535:
>>> Ich hoffe das ist nur hier ein Schreibfehler.
>>>> Dafür werden die unteren 4 Bits des PORTC (PC0 – PC3) verwendet. RS liegt
>>>> auf PC4, EN auf PC4. RW wird über PB0 angesteuert.
>>
>> Ist kein Eigenbau im Einsatz... LCD direct am Board
>
> Hast Du einen Multiplexer drin, der PC4 wegen der Doppelnutzung
> umschaltet und natürlich auch ein Latch?

Sory war Tippfehler!

(RS = Register select) <-> PORTC PortBit 4
(EN = Enable)          <-> PORTC PortBit 5

[Aloysius P. (Firma: FBI) (a_pendergast)]

Invisible Man schrieb im Beitrag #6342531:
> So, wie Du das beschreibst, liegt es an AVR Studio 7. Ich habe den Dreck
> auch wieder heruntergeworfen, weil er schwerfällig und fehleranfällig
> ist.
>
> Mache Studio 4.19 drauf. Das haut hin.

Halte ich für fast ausgeschlossen.... denn der Code läuft auf dem 
SDK600. Ich werde das ganze auch noch mal auf einen DIP 328P Flashen un 
auf dem Breadbord in minimalconfig xchecken..

[Veit D. (devil-elec)]

Hallo,

also das/die Shields sind keine Eigenbauten?

Ansonsten solltest du nochmal in Kurzform notieren welche Software 
(deine oder Arduino) worauf funktioniert und wo nicht. Ich blicke 
aktuell nicht mehr durch.

[Philipp K. (philipp_k59)]

Aloysius P. schrieb:
> wird der 4-Bit Modus verwendet. Dafür werden die unteren 4
> Bits des PORTC (PC0 – PC3) verwendet. RS liegt auf PC4, EN auf PC4. RW
> wird über PB0 angesteuert.

Nochmal..wie schon vorher geschrieben der Nano besitzt kein PC0-PC3, an 
welchen Digital Pins sind die 4 Bits angeschlossen? Quelltext der LCD 
initialisierung?

[Stefan F. (Gast)]

Aloysius P. schrieb:
> Nein HW kann es nicht sein, denn: Über Arduino IDE unter benutzung der
> selben Ports läuft alles.

Also bist du der Meinung, dass es an der Software liegen muss. Wie 
sillen wir dir nun helfen, ohne dass du sie vorzeigst?

Wie gesagt könnte es am Reset verhalten (insbesondere dem Timing) sein. 
Das Arduino Modul startet vielleicht schneller, als dein 
Entwicklungsboard und die Software von Arduino berücksichtigt dies 
angemessen, während es deine Software nicht tut.

Das wäre ein mögliches Szenario.

[Stefan F. (Gast)]

Philipp K. schrieb:
> wie schon vorher geschrieben der Nano besitzt kein PC0-PC3

Dann guck mal auf das obige Bild in 
Beitrag "Re: HILFE Seltsames Verhalten Atmega 328P auf Arduino-Board mag Code nicht"

Ich sehe sie dort auf der rechten Seite.

[Veit D. (devil-elec)]

Philipp K. schrieb:
> Nochmal..wie schon vorher geschrieben der Nano besitzt kein PC0-PC3, an
> welchen Digital Pins sind die 4 Bits angeschlossen? Quelltext der LCD
> initialisierung?

Das ist wiederholt falsch. PC0 ... PC5 sind herausgeführt.

[Philipp K. (philipp_k59)]

Ah ups sorry, hatte es auf dem Rechner verlegt und bin wohl bei google 
Bilder am Pinout des "Nano Every" vorbeigekommen.

Bei den Nano Clone Boards ist wohl manchmal A0-A? verkehrt herum 
rausgeführt.. hatte ich nebenbei noch in der Bildersuche gesehen.

[Aloysius P. (Firma: FBI) (a_pendergast)]

Philipp K. schrieb:
> Ah ups sorry, hatte es auf dem Rechner verlegt und bin wohl bei google
> Bilder am Pinout des "Nano Every" vorbeigekommen.
>
> Bei den Nano Clone Boards ist wohl manchmal A0-A? verkehrt herum
> rausgeführt.. hatte ich nebenbei noch in der Bildersuche gesehen.

Ich denke, dass kann es auch nicht sein, denn das Arduino kompilierte 
Beispiel läuft mit der selben PORT und Pin Zuordnung einwandfrei.

[Aloysius P. (Firma: FBI) (a_pendergast)]

Stefan ⛄ F. schrieb:
> Aloysius P. schrieb:
>> Nein HW kann es nicht sein, denn: Über Arduino IDE unter benutzung der
>> selben Ports läuft alles.
>
> Also bist du der Meinung, dass es an der Software liegen muss. Wie
> sillen wir dir nun helfen, ohne dass du sie vorzeigst?


Ich bin eigentlich nicht dieser Meinung. Denn auf dem SDK600 was nichts 
anderes macht als den 328P in Minimalkonfig zu beschalten läuft es.



> Wie gesagt könnte es am Reset verhalten (insbesondere dem Timing) sein.
> Das Arduino Modul startet vielleicht schneller,

hab ich auch gedacht. Deshalb vor die Init 1000ms delay gepackt.. macht 
keinen unterschied.


> als dein
> Entwicklungsboard und die Software von Arduino berücksichtigt dies
> angemessen, während es deine Software nicht tut.

Siehe oben

> Das wäre ein mögliches Szenario.

Habe ich auch schon durch...

[Stefan F. (Gast)]

Aloysius P. schrieb:
>>> Nein HW kann es nicht sein,
>> Also bist du der Meinung, dass es an der Software liegen muss.
> Ich bin eigentlich nicht dieser Meinung.

Na dann: Viel Spaß. Schön dass alles funktioniert.

Kleiner Tipp: Überprüfe deine Annahmen, und zwar alle. Und fnde dich 
dami9t ab, dass wir dir nur helfen können, wenn du dein Projekt 
vorzeigst: Schaltplan. Fotos, Quelltext, Projekteinstellungen (falls du 
kein Makefile verwendest). Nur dann kannst du weiter kommen.

[Philipp K. (philipp_k59)]

Aloysius P. schrieb:
> Ich denke, dass kann es auch nicht sein, denn das Arduino kompilierte
> Beispiel läuft mit der selben PORT und Pin Zuordnung einwandfrei.

Dann schick doch wenigstens mal ein Foto vom Nano..

also lies sich nicht ganz ersehen.. ein Sketch der Arduino IDE lässt 
sich mit "über Programmer" hochladen und funktioniert auf dem STK600?

Also im Prinzip das gleiche Programm in der IDE mit dem gleichem 
Programmer in der IDE, nur die Platine getauscht funktioniert?

Dann ist es die Verdrahtung oder Quartz Taktung, bzw falsche Einstellung 
der Taktrate in Arduino. (FCPU)

[Aloysius P. (Firma: FBI) (a_pendergast)]

Vielen Dank an alle die versucht haben zu helfen!

Mittlerweile nach dem ich den schönen Tag anstatt draussen am Computer 
verbracht habe, bin ich der Sache auf die Schliche gekommen.

Ich frage ja das Enable Bit ab, ob der 44870 noch busy ist. Hier ist bei 
einem Lo auf D7 des LCD frei. Ich mache die Abfrage über Pin5 PORTC. 
Offensichtlich klapp hier die Abfrage nicht. So das die Routine die 
Bussy checkt in eine Endlosschleife geht. Ich habe diese Abfrage durch 
ein delay von 0,5ms ersetzt und das ganze läuft nun fehlerfrei.

In the end of the day tatsächlich weder HW noch SW Fehler, lediglich 
eine Inkompatibilität zwischen beiden in dem speziellen Fall.

Ich werde mich jetzt mal auf die Suche machen und versuche 
herauszufinden warum offensichtlich PC5 auf den Arduino-Boards nicht 
durch den 44870 auf lo gezogen werden kann.

[Stefan F. (Gast)]

Aloysius P. schrieb:
> In the end of the day tatsächlich weder HW noch SW Fehler, lediglich
> eine Inkompatibilität zwischen beiden in dem speziellen Fall.

Da würde ich aber auch weiter nachforschen, sonst wirst du in Zukunft 
noch weitere mysteriöse "Inkompatibilitäten" bekommen, sie sich 
aufhalten.

An PC5 ist bei diesem Board normalerweise absolut nichts besonderes.

[Einer K. (Gast)]

Stefan ⛄ F. schrieb:
> An PC5 ist bei diesem Board normalerweise absolut nichts besonderes.
Es könnte sich dort ein Pullup für I2C befinden.

[Stefan F. (Gast)]

Arduino Fanboy D. schrieb:
> Es könnte sich dort ein Pullup für I2C befinden.

Und wenn schon? Stört nicht.

[Rolf D. (rolfdegen)]

Hallo Aloysius

Vielleicht liegt es daran, wie du im 4Bit-Modus die Abfrage des 
Busy-Flags programmiert hast (siehe Bild).

Gruß Rolf

[Jörn P. (jonnyp)]

Aloysius P. schrieb:
> (RS = Register select) <-> PORTC PortBit 4
> (EN = Enable)          <-> PORTC PortBit 5

Aloysius P. schrieb:
> Ich frage ja das Enable Bit ab, ob der 44870 noch busy ist. Hier ist bei
> einem Lo auf D7 des LCD frei. Ich mache die Abfrage über Pin5 PORTC.

Das E (Enable)hat nix mit der busy Abfrage zu tun. Im 8-bit mode ist das 
busy flag auf D7 des DATENBUS. Im 4-bit mode eben auf dem höchsten bit 
in der ersten Abfrage (Datenbus high nibble).