mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PIC 18F1330 hängt sich auf


Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

seit einiger Zeit sollte eigentlich mein Temperaturlogger im Garten 
arbeiten und über das ganze Jahr ein wenig Statistikmaterial liefern, er 
misst stündlich die Temperatur über einen DS1822 der übrigens 
erstaunlich genau arbeitet und speichert sie in einem 32K EEPROM ab. Das 
System ist auf extrem Low Power getrimmt, wacht RTC gesteuert nur einmal 
die Minute auf und arbeitet mit einer kleinen Solarzelle samt 3 AAA 
Akkus ohne Spannungsregler, der 1330 hat eine interne Referenz, die 
Spannung pendelt zwischen 3.0V und 4,5V je nach Sonne. Am Netzteil 
getestet klappte das auch alles, er schlief ein und wachte wieder auf. 
Unterschreitet sie 3.0V greift die Low Voltage Detection und schaltet 
ab. Der 1330 wird mit internem RC Osillator betrieben, zwischen 4 Mhz 
und 125 khz. Um äusserlich zu sehen, dass er arbeitet blitzt eine blaue 
LED, die mit nur 100uA ausreichend hell ist. Das Energie Management habe 
ich bis ins kleinste Detail ausgearbeitet, er schätzt anhand der 
Batteriespannung ab ob gerade eine Sonnenwoche ansteht oder eine 
Regenzeit, passt sich den Jahreszeiten durch den Kalendar der RTC 
entsprechend an und funkt nur durch den RFM12 an seine Basisstation wenn 
genügend Energie da ist.

Mein Dank auch an den Herrn Heldt hier im Forum, der mir die PCF8563 RTC 
verkaufte, die wirklich genau läuft, wenn man sie mit einem Trimmer 
trimmt und die auch beliebig oft abgefragt werden kann ohne falsch zu 
gehen.

Nun ist es aber so, dass sich der 18F1330 nach etlichen Stunden 
plötzlich aufhängt, dabei hat er nur einen einzigen ResetWatchdog Befehl 
im Code, der WDT schlägt nach 10s zu. Das System steht einfach, dabei 
kann das doch gar nicht sein. Der WDT hängt allerdings ebenfalls am 
INTRC Oszillator.

Hat jemand ähnliche Erfahrungen gemacht dass PIC einfach stehenbleiben? 
Ich überlege, ob ich einen 8 Pinner spendiere als externem Watchdog.

Gruss,
Christian

Autor: 3355 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>PIC 18F1330 hängt sich auf

Jööööö. Mein Beileid.

>Hat jemand ähnliche Erfahrungen gemacht dass PIC einfach stehenbleiben?

Nein. Das ist ein Programmfehler. Ueblicherweise auf Zeile 42.

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Niveau dieses Forums befindet sich leider auch im freien Fall.....

Autor: 3355 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So. Ist es das ? Also der Ansatz bisher ist gut. Ueber das Programm kann 
ich eher wenig sagen, da unbekannt. Einen sauberen strukturierten 
Programmaufbau vorausgesetzt, sollte ein fehlerfreies Programm machbar 
sein. Sorry. Eine Hauptschleife und eine Timer-Tick und es sollte 
relativ einfach zu zuverlaessig laufen.

Autor: Gast7777 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bella bella bella marie sie hängt sich auf ich schneid sie ab
morgen früh!!! nicht von mir

Gast

Autor: Karsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das machen die PIC`S gern!

Autor: 3355 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deshalb fliegen auch 95% der PIC produkte umgehend in die Tonne....

Autor: Karsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yes!

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

>Nun ist es aber so, dass sich der 18F1330 nach etlichen Stunden
>plötzlich aufhängt, dabei hat er nur einen einzigen ResetWatchdog Befehl
>im Code, der WDT schlägt nach 10s zu.

die Anzahl der ResetWatchdog-Befehle ist ja weniger ausschlaggebend als 
der Zeitpunkt ihrer Ausführung. Überlege, wo im Programm setzt du den 
WDT zurück und kann das im Zusammenhang mit:

>Das System steht einfach, dabei kann das doch gar nicht sein. Der WDT hängt 
>allerdings ebenfalls am INTRC Oszillator.

überhaupt zu deinem konkreten Problem führen? Du schreibst leider nicht 
was die Kontroll-LED macht wenn der PIC 'stehenbleibt'

>Hat jemand ähnliche Erfahrungen gemacht dass PIC einfach stehenbleiben?

Nein, bisher hat sich immer ein 'Schuldiger' gefunden. Wie siehts denn 
mit dem externen EEPROM aus, I2C oder SPI? (Vielleicht 'hängt' da 
was...?)

>Ich überlege, ob ich einen 8 Pinner spendiere als externem Watchdog.

Ich befürchte, das wird das Problem nicht lösen.

>das machen die PIC`S gern!

Unfug! Lass Dir da nichts einreden.

Gruss,
Edson

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Edson,

also wenn ich beim CCS 4.1 Compiler den delay Befehl ohne restart_wdt 
ausführen lasse, also #use delays (Internal, 4MHZ) dann muss jede 
Endlosschleife im Code zwangsläufig einen Reset auslöen, egal wo. Bei 
den EE Routinen sind einige Schleifen dabei, etwa das Warten auf Ende 
des Schreibens usw. Nur sleep setzt ihn zurück. Es gibt eben nur den 
einzigen reset_wdt Befehl in der Hauptschleife. Befindet sich der PIC im 
Sleep Zustand wacht er bei Überlauf auf, befindet er sich in der 
Codeausführung führt er einen Hardwarereset durch. Die LED blinkt nicht 
mehr, wenn er stehenbleibt, ist klar.

Ein externer WDT ist auf jeden Fall eine doppelte Sicherheit....

Alternativ könnte ich einen Quarz verwenden und die Fail-Safe Struktur 
des Chips nutzen, der auf einen anderen Osci umschaltet, sobald der 
primäre versagt aber dann verliere ich wieder zwei Pins, die ich 
dringend brauche.

Das Errate Sheets verrät nichts besonderes, nur die üblichen kleinen 
Bugs in der Eusart etc. die ich eh nicht brauche.

Andererseits: An meiner Wand hängt ein schickes Lochrasterboard mit 
LCD-Uhrenanzeige mit 18F442, läuft seit zwei Jahren pausenlos durch.

Gruss,
Christian

Autor: Karsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bei den EE Routinen sind einige Schleifen dabei, etwa das Warten auf Ende
> des Schreibens usw.

und die haben ein Ausgang im Fehlerfall? PICPICPIC macht das Huhn!!!!

ps das beschreibt diese (und andere) Macken!

warum sind so viele Leute mit dem Entwanzen von Standard-Befehlsfolgen
beschäftigt? und warum nicht nicht ein USB µC 18F4550 in der dritten
Variante der klaglos nur (ich verlange ja nicht viel) funktioniert.!!!
Warum wird kleinern Unternehmen entsprechende Unterstützunng verwehrt?

Antwort:

AVR

von einem, der seit 20 Jahren mit dem Zeug rummacht

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Karsten
>und die haben ein Ausgang im Fehlerfall? PICPICPIC macht das Huhn!!!!

Lass uns doch mal an deinem umfangreichen Erfahrungsschatz teilhaben.
Was läuft bei dir schief ?

Ich schon ein paar PIC16 und PIC18 verbaut. Und damit meine ich nicht
10 oder 100. Die laufen alle noch.

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>also wenn ich beim CCS 4.1 Compiler den delay Befehl ohne restart_wdt
>ausführen lasse, also #use delays (Internal, 4MHZ) dann muss jede
>Endlosschleife im Code zwangsläufig einen Reset auslöen, egal wo.

Ok, von CCS war vorher noch nicht die Rede. Dazu kann ich nicht viel 
sagen, ich kenne den Compiler nicht. Hast du dir die Assembly mal 
angeschaut?

Ohne den .ASM-Code kann man nur raten, die Lösung mit einem weiteren 
Watchdog halte ich aber für eher 'unelegant'.

Gruss,
Edson

Autor: Pete K. (pete77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht ein Stack-Overflow oder falsch referenzierter Pointer ?

Autor: Christian J. (elektroniker1968)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>> Vielleicht ein Stack-Overflow oder falsch referenzierter Pointer ?

Danke, werde ich mak nachschauen, die Stacktiefe ist allerdings nur 7 
und kann maximal 32 sein. INTs benutze ich nicht.

Wie aber noch gesagt, der Code kann soviele Fehler haben wie er will, 
eine Fehlerbehandlung brauche ich nicht, der PIC kann eh darauf nicht 
reagieren, er hat ja nichts womit er einen EEPROM Fehler beheben kann. 
Man kann nur hoffe, dass ein Reset das Problem löst. Und der WDT läuft 
stur durch, wird er nicht resettet wegen einer fehlerhaften 
Endlosschleife reisst er die Leine und führt den HW Reset aus. Das 
müsste aber bekannt sein, daher verstehe ich die Fragen nicht ob der 
Code richtig ist. Das weiss man bei einem Compiler nie so ganz, bei 
keinem.

Ich wollte eigentlich nur wissen, ob es bekannt ist, dass PIC mit INTRC 
Oszi ab und zu mal stehen bleiben.

PS: Der Glaubenskrieg AVR - PIC gehört hier nicht hin.

Anbei mal der EE Code als Beispiel warum ich CCS benutze der eine HAL 
hat, macht einfach mehr Freude und weniger Code.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hab mir das Ganze nicht angeschaut, mit PIC habe ich auch nichts am 
Hut, aber:
der WDT löst einen Reset aus, weil der Kram irgendwo hängen geblieben 
ist.
Schreibroutine, Lesen des Sensors, Lesen des RTC.
Ist denn Sichergestellt, daß diese Peripehrie nach dem Reset in einen 
definierten Zustand gebracht wird (gebracht werden kann), damit das Ding 
nicht gleich wieder hängt, weil z.B. der RTC garnicht antworten kann, 
weil er in einem undefinierten Zustand der Übertragung hängt und da 
nicht rauskommt?

Sind also die Init-Routinen in der Lage, das System aus JEDEM Zustand zu 
initialisieren und können die externen ICs das auch?

Gruß aus Berlin
Michael

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>der WDT löst einen Reset aus, weil der Kram irgendwo hängen geblieben
>ist.
So wie ich das verstanden habe löst er eben nicht aus obwohl
das Programm steht.

Ich schätze mal das der PIC im Sleepmode ist und der WDT ihn
da nicht rausholt.
Zwar habe ich schon so manches Programm für PICs geschrieben (auch
mit CCS) aber den Sleepmode habe ich noch nie benutzt.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim AVR-GCC gibt es ne gemeine Sleep-Fallgrube:

Wenn man die Sleep-Funktionen benutzt, kann man sich für alle Zeiten 
schlafen legen und nie wieder aufwachen.

Die Bibliotheksfunktionen dürfen nicht benutzt werden, da nicht 
interruptfest, sondern man muß das Sleep direkt im Sleepmoderegister 
enablen und direkt den Sleep-Befehl ausführen.

Nur so ist sichergestellt, daß der Aufwachinterrupt garantiert enabled 
ist, bevor die CPU in den Sleepmode geht!

Könnte mir beim PIC ein ähnliches Problem vorstellen.


Peter

Autor: 3355 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seltsamerweise benutzt der Poster keinen INT. Wie auch immer das gehen 
soll.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
3355 wrote:
> Seltsamerweise benutzt der Poster keinen INT. Wie auch immer das gehen
> soll.

Ich hab mir das Programm nicht angesehen (PICs sind mir zu kompliziert).
Ich hatte nur vermutet, daß der RTC den PIC zyklisch aufweckt wegen 
Strom sparen.

Beim AVR hätte man keinen extra RTC benötigt, da der ja intern mit T2 
einen 32kHz-Quarz zählen kann, während der Haupttakt und die CPU 
schläft.


Peter

Autor: 3355 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mal davon ausgegangen, dass ein PIC18 praktisch identisch zu 
einem AVR ist. Bei einem AVR lohnt es sich fuer Stromsparanwendungen 
einen externen RTC zu verwenden. Eine DS1302 zB kommt mit 200nA durch, 
was man mit einem AVR als RTC nicht schafft.
Dass keine Interrupt verwendet wird ist eine Aussage des Posters. Hat 
mich nur gewundert, wie das Aufwecken denn gehen soll. Scheint ein Murks 
zu sein. Ohne Tick macht man nicht viel ausser Delayloops.

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

natürlich habe ich keinen  Murks programmiert, mache das ja nicht zum 
ersten Mal. Die RTC löst am EXT3 Pin eine Flanke aus, diese Flanke setzt 
intern ein INT Flag im PIC. Der Global INT ist aber gesperrt, daher wird 
keine Routine angesprungen. Ich frage das Flag manuell ab. Der PIC wacht 
dadurch auch auf. Externe RTC deshalb weil Lösungen mit 32khz Quarz zu 
ungenau sind, die am Timer 1 arbeiten, die PCF8563 ist super am I2C Bus.

Das Problem scheint aber gelöst zu sein, ein Poster hier hat schon 
richtig getroffen, nämlich, dass die Peripherie nicht richtig 
initialisiert wurde. Ich boote den PIC nun mit 256khz hoch und schalte 
dann erst um nach 100ms, ausserdem habe ich den I2C Bus von 400khz auf 
100khz reduziert. Seitdem läuft er durch, er schien nach dem Reset zu 
hängen, wo weiss ich nicht.

Es ist aber bekannt dass die PIC manchmal probleme haben die 40 Mhz zu 
fahren. Das Thema ist bekannt, sie werden dann schonmal instabil, daher 
empfehlen die FAE auch nicht schneller als 16 Mhz.

Nochwas: Wenn man die PICs einmal durchschaut hat und ich arbeite seit 
fast 12 Jahren mit denen, dann sind das super Dinger, genau wie die Lite 
Serie von ST, die kaum jemand im Bastelbereich einsetzt. Die Dinger 
fahren sich mit men Oldtimer, die Schltung hakt und mein Vater kann ihn 
nicht fahren aber wenn man es erstmal gelernt hat mit Zwischengas dann 
fährt er sich super.

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

>Wie aber noch gesagt, der Code kann soviele Fehler haben wie er will,
>eine Fehlerbehandlung brauche ich nicht, der PIC kann eh darauf nicht
>reagieren, er hat ja nichts womit er einen EEPROM Fehler beheben kann.

da hast Du mich falsch verstanden oder ich habe mich ungenau 
ausgedrückt. Im Prinzip habe ich nicht von fehlerhaften EEPROM-Zugriffen 
gesprochen sondern wollte allgemein auf mögliche Probleme der 
Kommunikation (mit der Peripherie) hinweisen. Die Frage nach der 
Ansteuerung des EEPROM war nur ein Beispiel.

>daher verstehe ich die Fragen nicht ob der Code richtig ist.

Jetzt aber schon, oder? Die Initialisierung gehört doch zum Programm.

>Das weiss man bei einem Compiler nie so ganz, bei keinem.

Da hast wohl recht (daher arbeite ich gerne mit ASM). Aber sollte man 
nicht immer wissen was der Compiler macht, bzw. bei bestimmten 
Funktionen wider erwarten nicht macht? Damit man Aussagen treffen kann 
wie z.B. Peter Dannegger(24.05.2008 11:34).

>Das Problem scheint aber gelöst zu sein,

Gratuliere, dann passt es ja jetzt!

>Wenn man die PICs einmal durchschaut hat ... dann sind das super Dinger

Absolut!


@3355
>Ich bin mal davon ausgegangen, dass ein PIC18 praktisch identisch zu
>einem AVR ist.

Na ja, hoffentlich hast du jetzt gemerkt dass derlei Vergleiche keinen 
Sinn machen ;)


>Ich schätze mal das der PIC im Sleepmode ist und der WDT ihn
>da nicht rausholt.

Wie gesagt, derlei Phänomene sind mir nicht bekannt.

Gruss,
Edson

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Edson,

danke für Deine Antwort. Es ist ein Unterschied, um ein System mit 
Power-Up aufstartet oder aber durch einen Reset neu bootet. Der I2C Buss 
man ja auch einen definierten Pegel haben, damit die internen 
Statemachines der Bausteine  einen Reset auslösen. Damit ein PIC neu 
bootet reicht ein Blitz bei einem Gewitter aus oder eine Bohrmaschine, 
die nebenan betrieben wird.

Manche Probleme lösen sich, wenn man das Problem anders formuliert ohne 
dass man genau weiss, warum es vorher so war. Das sind dann die 
Probleme, die einem Sorgen bereiten, weil man nicht weiss woran es lag.

Ich bin zu faul den ASM des Compilers noch zu untersuchen, gebe auch zu 
dass ich PIC Asm verlernt habe, seit 1998 wo ich den ersten Compiler 
benutzt habe, den Byte Craft, der völlig buggy war. PIC Asm sprechen ist 
wie das Gestammel eines Babys, es ist zwar ein orthogonaler RISC 
Befehlssatz aber komplexe Sachen lassen sich damit kaum lösen, ich 
benutze intensiv Strukturen und Zeiger, bin mit Pascal und C 
aufewachsen. Routinen teste ich daher mit einer Testumgebung im 
Programm, je weniger man den HAL (Hardware Abstraction Layer) des CCS 
Compilers benutzt, der die Hardware abstrahiert, umso sicherer kann man 
sein, dass keine Compilerfehler Ursache sind.

Die PIC haben ihre Macken, Microchip wirft teilweise Chips auf den 
Markt, die gar nicht lauffähig sind "Unter bestimmten Umständen kann es 
zu einem Programmabsturz kommen, nähere Umstände sind noch nicht bekannt 
"steht es da im Errata Sheet. Aber selbst der ARM7 den ich noch von NXP 
benutze strotzt vor Fehlern, selbst 10 Jahre nach Erscheinen als ich 
noch VHDL Muckl bei NEC war und wir die Peripherie dafür designten.

Lassen wir es gut sein, heute hat mich der ADAC auf der A44 wieder 
reingeholt, weil meine Nockenwelle im Fiat X1/9 den Kopf gesprengt hat. 
Ab Montag heist es Motor zerlegen.  Das sind wenigstens reale Probleme 
mit echter Hardware :-)

Gruss,
Christian

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.