Verstehe meinen Pic nicht!

Gast #1986495
Lesenswert?

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)
1
PIC18F2550 found (Rev 0x5)
2
Erasing Target
3
Programming Program Memory (0x0 - 0x387F)
4
Verifying Program Memory (0x0 - 0x387F)
5
Running Target
6
PK2Error0027:  Failed verify (Address = 0x154 - Expected Value 0x6A03 - Value Read 0x3603)
7
PICkit 2 Ready
8

9
Programming Target (22.12.2010  15:16:31)
10
PIC18F2550 found (Rev 0x5)
11
Erasing Target
12
Programming Program Memory (0x0 - 0x387F)
13
Verifying Program Memory (0x0 - 0x387F)
14
PK2Error0027:  Failed verify (Address = 0x236 - Expected Value 0xE03 - Value Read 0x404)
15
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
1
#pragma config FOSC=HS, WDT=OFF, PWRT = ON, DEBUG = ON, LVP = OFF, PBADEN = OFF

Woran könnte es liegen?
Gast #1992330
Lesenswert?

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!
Gast #1992687
Lesenswert?

>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.
Gast #1994085
Lesenswert?

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.
#1994147
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren