Verstehe meinen Pic nicht!

[noobuntu (Gast)]

Hallo alle zusammen,

ich kämpfe gerade mit einem Pic18f2550. Bin dabei ein Programm zur 
Ansteuerung von Displays mit t6963 Controller von einem 18f4520 (dort 
funktioniert es einwandfrei) auf den oben genannten kontroller zu 
portetieren.

Das Programm wurde nach einigen kleinen Anpassungen in den Defines auch 
anstandslos compiliert (so war es auch gedacht). Nun das eigentliche 
Problem. Der Controller wird vom PicKit2 erkannt, auch schafft er es die 
Daten auf den 18f2550 zu schreiben, nur beim "Verify Programm Memory" 
kommt eine Fehlermeldung und der Controller weigert sich in den Debugg 
Modus zu gehen.

Hier die Fehlermeldung (bzw. von 2 Versuchen)

PIC18F2550 found (Rev 0x5)
Erasing Target
Programming Program Memory (0x0 - 0x387F)
Verifying Program Memory (0x0 - 0x387F)
Running Target
PK2Error0027:  Failed verify (Address = 0x154 - Expected Value 0x6A03 - Value Read 0x3603)
PICkit 2 Ready

Programming Target (22.12.2010  15:16:31)
PIC18F2550 found (Rev 0x5)
Erasing Target
Programming Program Memory (0x0 - 0x387F)
Verifying Program Memory (0x0 - 0x387F)
PK2Error0027:  Failed verify (Address = 0x236 - Expected Value 0xE03 - Value Read 0x404)
PICkit 2 Ready

Das komische ist, dass wenn ich die einzelnen Ports vertausche, alles 
(das Draufladen und Debuggen) ohne Probleme funktioniert. Mit Ports 
vertauschen meine ich, das an PortB (von 0 bis 7) eigentlich die 
Datenleitungen liegen und an PortA (von 0 bis 5) die Controllleitungen 
(Enable, Command/Daten usw.). Vertausche ich nun PortA mit PortB tauchen 
keine Probleme auf!

Die Config des p18f2550

#pragma config FOSC=HS, WDT=OFF, PWRT = ON, DEBUG = ON, LVP = OFF, PBADEN = OFF

Woran könnte es liegen?

[holger (Gast)]

Mach mal einen Pullup 10k an den CE Pin vom Display.

[noobuntu (Gast)]

Hallo,

nach überstandener Weihnacht habe ich nun wieder Zeit mich meinem 
Projekt zu widmen. Ich glaube ich habe den Fehler gefunden. Die Eingänge 
des Displays hängen an PortB. Da PB7 und PB6 aber zum flashen und 
Debuggen des Controllers genutzt werden, gibt es Konflikte auf diesen 
Leitungen und die Signale werden verfälscht. Das abschalten der 
Debuggfunktionen, sowie das anbringen zweier 10k Pullups haben leider 
nichts gebracht!

Hat jemand eine Idee? Ich bin für jede Dankbar!

[Dieter (Gast)]

Ich kenne den speziellen PIC nicht, aber kann man sich nicht selber 
raussuchen, welche PINs für welche Peripherie genutzt werden?
Also quasi einfach andere PINs für's Display nehmen?

[holger (Gast)]

>Das abschalten der
>Debuggfunktionen, sowie das anbringen zweier 10k Pullups haben leider
>nichts gebracht!

Die Pullups an PB6 und PB7 bringen gar nichts. Du musst
verhindern das das Display beim brennen auf auslesen
geht. Dann liegen die Ausgänge des Displays auf PB6 und PB7.
Die Pullups gehören an CE oder RD. Nur da bringen sie was.
Debuggen mit angeschlossenem Display kannste wohl knicken.
Evtl. gehts doch wenn du von PB6 PB7 jeweils einen Serienwiderstand
um 2k2 zu den Displaypins legst.

[Ulf (Gast)]

Hatte gerade das gleiche Problem mit gleichem PIC18f2550. An RB0..7 
hängt ein Graphikdisplay und ein 16x2. Bei mir lief es mit 560 Ohm in 
den Leitungen von RB6..7 zum Display und 470 Ohm von RB6..7 zum ISP- 
Stecker.
Programmieren geht dann, aber auch nur, wenn die /RD- Leitung einen 
Pullup hat(damit nicht schon beim RESET irgendwas vom Display gelesen 
wird). Debuggen funktioniert aber leider nicht, weil ja der Debugger 
andauernd im Datenbus rumfunkt.
Im Prinzip habe ich also Holgers Text auch so erlebt und befolgt.

Fazit: Nie wieder Geiz bei den Pins, das Gemache danach ist aufwendiger.

ulf.

[hans Flip (Gast)]

Verstehe meinen Pic nicht!

suess ;-)

klingt so wie:  Verstehe meine Frau nicht!
oder:  Verstehe meine Welt nicht!

[B e r n d W. (smiley46)]

@Hans

Bei mir ist es grad andersrum:
Mein PIC versteht mich nicht!

[Flip Hans (Gast)]

Und ich verstehe die ganze Welt nicht mehr.

Warum nimmst Du für so eine Anwendung eigenlich nen PIC und keinen 
Atmel?

[Sebastian M. (noobuntu)]

holger schrieb:
> Die Pullups an PB6 und PB7 bringen gar nichts. Du musst
> verhindern das das Display beim brennen auf auslesen
> geht. Dann liegen die Ausgänge des Displays auf PB6 und PB7.
> Die Pullups gehören an CE oder RD. Nur da bringen sie was.
> Debuggen mit angeschlossenem Display kannste wohl knicken.
> Evtl. gehts doch wenn du von PB6 PB7 jeweils einen Serienwiderstand
> um 2k2 zu den Displaypins legst.

Ok, jetzt habs auch ich verstanden! Meine Lösung war etwas trivialer. 
Hatte noch einen p16f886 herumliegen und habe bei diesem dann PortC 
(PortC ist beim p18f2550 schlecht verwendbar, da einige Pins wegen der 
USB Funktion nicht als ganz normale IOs verwendet werden können) anstatt 
PortB benutzt. Das Ansteueren des Display funktioniert jetzt 
einwandfrei.

Flip Hans schrieb:
> Und ich verstehe die ganze Welt nicht mehr.
>
> Warum nimmst Du für so eine Anwendung eigenlich nen PIC und keinen
> Atmel?

Wollte ich eigentlich auch (bin eigentlich Atmel Jünger), doch leider 
war es eine Vorgabe einen Pic zu benutzen, da dieses ganze Projekt für 
eine Schule ist und dort nur auf 8051 und Pic gelernt wird.

[holger (Gast)]

>Warum nimmst Du für so eine Anwendung eigenlich nen PIC und keinen
>Atmel?

Weil nicht jeder so beschränkt ist wie du?