16F887 start niet met interne oscillator

leeg

[Bericht gewijzigd door benleentje op zaterdag 29 augustus 2009 20:27:50 (96%)]

Op 29 augustus 2009 20:12:54 schreef benleentje:

Het leuke eraan is voornamelijk de interne oscillator.

Volgens mij moet ik iets megagroots over het hoofd zien...

Welke interne oscilator zeker niet in de PIC16F877.

Gewoon geweldig om iedere keer te constateren dat men 16F877 en 16F887 door elkaar haspelt. De 16F887 heeft een interne oscillator in tegenstelling tot zijn voorganger de 16F877.

[Bericht gewijzigd door High-Voltage op zaterdag 29 augustus 2009 20:51:36 (44%)]

leeg

[Bericht gewijzigd door benleentje op zaterdag 29 augustus 2009 20:27:38 (98%)]

Op 29 augustus 2009 20:19:08 schreef benleentje:
Ik lees ook verkeert ik dacht dat het over een 16F877 ging. Weet je ook zeker dat het een 887 is die er in je schakeling zit.

Dat zijn fouten die zelfs beginners van het eerste uur niet kunnen maken. Als je in je code zet 16F887 en in werkelijkheid heb je een 16F877 dan wil hij gewoon niet eens geprogrammeerd worden. Zelfs een 16F628 en 16F648 zijn op die manier niet te verenigen...

Maar om expliciet te antwoorden: jup er zit een 16F887 in hoor.

Edit:
Je hoeft je berichten niet weg te doen hoor... Ik ben al heel blij dat iemand mn topic leest en hulp probeert te bieden. Dat het jammer genoeg niet de oplossing is, tja dat is een ander verhaal. Reacties gewoon laten staan, zo maakt iemand anders niet meer dezelfde lees/denk/redeneer fout

[Bericht gewijzigd door High-Voltage op zaterdag 29 augustus 2009 20:53:47 (17%)]

Uit de Assemblerfile van dit project (in PicBasic) haal ik het volgende:

CONFIG_REQ
__CONFIG _CONFIG1, INTRC_OSC_NOCLKOUT & WDT_OFF & DEBUG_OFF & FCMEN_OFF & IESO_OFF & BOR_OFF & CPD_OFF & CP_OFF & MCLRE_OFF & PWRTE_ON
__CONFIG _CONFIG2, WRT_OFF & BOR21V

Uit een template van Microchip haal ik dit:

    __CONFIG    _CONFIG1, _LVP_OFF & _FCMEN_ON & _IESO_OFF & _BOR_OFF & _CPD_OFF & _CP_OFF & _MCLRE_OFF & _PWRTE_ON & _WDT_OFF & _INTRC_OSC_NOCLKOUT
    __CONFIG    _CONFIG2, _WRT_OFF & _BOR21V

Nu zie ik in de template (hetgeen waarvan ik weet dat het werkt overigens) dat er voor elke fuse een underscore staat, terwijl dat dat bij mijn file niet zo is. Ik weet niet waarom die underscore er staat of als er die überhaupt moet staan, maar kan er dit soms iets mee te maken hebben waarom het niet werkt?
Ik vermoed van niet, want de PIC reageert blijkbaar wel op het verschil tussen externe of interne RC oscillator...

Zo blij kwam je op mij niet over.

ASM
CONFIG_REQ            
__CONFIG _CONFIG1, INTRC_OSC_NOCLKOUT & WDT_OFF & DEBUG_OFF & FCMEN_OFF & IESO_OFF & BOR_OFF & CPD_OFF & CP_OFF & MCLRE_OFF & PWRTE_ON 
__CONFIG _CONFIG2, WRT_OFF & BOR21V 
ENDASM

Eerst regel en laatste regel wat doen die daar. Enig idee wat die commando's doen.
Heb je de help file van Proton al goed doorgelezen?

Kijk ook eens hier
www.picbasic.nl

Die zitten daar omdat ik mijn fuses in Assembler opgeef. Proton heeft wat moeite met de fuses van de 16F887.

_{De manier waarop iemand op een forum overkomt is moeilijk in te schatten door gebrek aan lichaamstaal. Mijn taalgebruik is soms nogal "koud" en to the point. Ik zal in het vervolg de smileys iets rijkelijker laten vloeien}

De config wordt op een vast adres weggeschreven. Mischien dat adres eens uitlezen om te kijken of dat wel goed gaat. In de hexcode is het de laatste 2 hex waarden. Tenminste bij 16F628. Hoe dat bij deze zit geen idee.

00400E 002007 50 3F

OP adres 2007 staat hier de config instelling

:02400E00C428C4
:02401000FF3E71

Dit zijn volgens mij de fuse settings uit een werkend stukje code.

:02400E00C430BC
:02401000FF3E71

En dit komt uit mijn laatste projectje.

Ze zitten beiden op hetzelfde adres, al begrijp ik niet helemaal hoe ik die 2400 en 2401 kan omzetten in 2007h en 2008h, maarja... De laatste regel fuses is identiek, de eerste is blijkbaar iets verschillend, maar dat komt waarschijnlijk omdat bij de eerste de fail save monitor ingeschakeld is en bij de tweede niet.

Edit:
Na de fail save monitor bij de tweede ingeschakeld te hebben krijg ik dit:

:02400E00C438B4
:02401000FF3E71

Even verder zoeken of er nog fuses verschillend zijn!

Edit2:
Blijkbaar had ik LVP_OFF niet opgenomen in mn fuses lijst. Nu ik die heb toegevoegd zijn beide hetzelfde. Nu hoop ik dat dit het probleem veroorzaakt heeft!! Morgen(middag) ga ik het testen.
Alleen vrees ik ervoor, want LVP heeft enkel maar betrekking op het programmeren en niet op de verdere werking zover ik mij herinner. Helaas, ik dacht een doorbraak gevonden te hebben.

Edit3:
Mogelijk dat ie door dat LVP gedoe in programmeermode blijft staan (zolang de programmer aangekoppeld is) waardoor de oscillator niet wil starten. Ik moet het echt proberen morgenmiddag, dan kan ik het met zekerheid zeggen.

Ik heb niet gezegt dat bij jouw PIC ook op 2007 of #400E moeten staan. Dat hangt van de flash grote af. Het staat aan het einde van het flash geheugen.

000000 000000 00 00 00 30 8A 00 71 28 A0 16 20 17 A0 17 0A 28
000010 000008 20 16 20 1E 20 12 20 1B 12 28 FE 39 A2 00 20 17
000020 000010 03 10 28 28 A0 1B 1A 28 A7 00 A0 17 2E 20 03 18
000030 000018 1F 28 27 08 32 20 03 18 1F 28 20 1E 28 28 83 16
000040 000020 11 15 11 19 21 28 83 12 20 13 A0 13 A0 12 20 11
000050 000028 28 14 03 1C 28 10 6C 28 4A 20 2F 28 43 20 22 08
000060 000030 A0 1A 01 38 93 00 83 16 14 19 34 28 83 12 A5 01
000070 000038 03 10 83 16 11 1F 6C 28 83 12 3E 28 3F 28 A5 0B
000080 000040 38 28 03 14 08 00 83 16 87 15 07 16 11 14 11 18
000090 000048 47 28 6C 28 83 16 91 14 91 18 4C 28 6C 28 A6 01
0000A0 000050 A5 00 FF 30 A5 07 03 1C A6 07 03 1C 6C 28 03 30
0000B0 000058 A4 00 E7 30 5D 20 51 28 A4 01 FC 3E A3 00 A4 09
0000C0 000060 03 1C 68 28 FF 30 00 00 A3 07 03 18 63 28 A3 07
0000D0 000068 00 00 A4 0F 62 28 08 00 83 13 83 12 03 13 00 00
0000E0 000070 08 00 28 30 94 00 83 16 31 30 93 00 80 30 94 00
0000F0 000078 83 12 A0 01 07 30 83 16 9F 00 85 01 83 12 8A 11
000100 000080 0A 12 86 28 05 12 63 00 8A 01 83 28 05 16 8A 01
000110 000088 43 20 F0 30 8A 01 04 20 8A 11 0A 12 28 1C 92 28
000120 000090 8A 01 82 28 E0 30 8A 01 04 20 48 30 8A 01 04 20
000130 000098 FF 30 8A 01 04 20 FF 30 8A 01 04 20 FF 30 8A 01
000140 0000A0 04 20 FF 30 8A 01 04 20 FF 30 8A 01 04 20 FF 30
000150 0000A8 8A 01 04 20 FF 30 8A 01 04 20 FF 30 8A 01 04 20
000160 0000B0 FF 30 8A 01 04 20 FF 30 8A 01 04 20 FF 30 8A 01
000170 0000B8 04 20 FF 30 8A 01 04 20 FF 30 8A 01 04 20 FF 30
000180 0000C0 8A 01 04 20 FF 30 8A 01 04 20 FF 30 8A 01 04 20
000190 0000C8 FF 30 8A 01 04 20 FF 30 8A 01 04 20 FF 30 8A 01
0001A0 0000D0 04 20 FF 30 8A 01 04 20 8A 01 1F 20 05 14 96 30
0001B0 0000D8 8A 01 4F 20 05 10 01 30 A6 00 45 30 8A 01 50 20
0001C0 0000E0 8A 01 D6 28
00400E 002007 72 3F

Code voor een 16F877 Uit bumble bee.
1^ste kolom is byte adress
2^de kolom is word adres
Andere kolomen hex waarden van programma code

Volgens de datasheet staan de fuses (net zoals bij de meeste PIC's denk ik) op 2007h en 2008h.
Ik kan echt geen verband zien tussen de eerste en tweede kolom overigens. Sequentieel is er een verband: de eerste kolom gaat per tien omhoog, de tweede afwisselend per acht en per twee.
De eerste kolom kan inderdaad het hexadecimaal adres zijn (gezien de letters die erin voorkomen), maar in de tweede kolom staat 2007, terwijl in de datasheet staat dat 2007h de fuses bevat. En 2007h is volgens mij een hexadecimaal getal.

We gaan in ieder geval de juiste richting uit

Programma tot de bare bones strippen, timers etc er uit.

Bij je scoopmeting is iets fout gegaan, 50Hz is wat je meet als er wat los zit.

Interne oscillator kan je ter controle terugvinden op een pin (indien is aangegeven met de fuses).

In OSCCON heb je aangegeven niet de interne osc als start-up te gebruiken.

Jup, 50Hz is inderdaad verdacht, maar aangezien ik iets had dat leek op een blokgolf met dutycyle 90% en geen sinus achtig iets ging ik er van uit dat het toch nog in orde was... Dat ik met verschillende C's terug 50Hz krijg is inderdaad dubbel zo verdacht.

Ik heb de interne oscillator een keer naar buiten gebracht (zie startpost), maar dan meet ik niets. Vandaar dat ik wist dat de oscillator niet liep en ik daar het probleem moest gaan zoeken.

OSCCON zou normaal goed moeten zijn. Bit 0 staat op 1 wat aangeeft kost wat kost de interne oscillator te gebruiken. Via de mux ingesteld met bit 6-4 zou ik op 8MHz moeten uitkomen.

Programma verder strippen lijkt me zinloos, dit is m.i. echt een fuses probleem. Zolang de oscillator niet loopt heeft geen enkele instructie betrekking tot enig verder verloop.

Bit 3, zie mijn post.

En nog eens meten met een RC oscillator.

[Bericht gewijzigd door Henry S. op zaterdag 29 augustus 2009 23:04:36 (51%)]

Ik kon niet echt uit je post afleiden dat het om bit 3 ging. Deze bit is overigens niet eens aanpasbaar, is maar read only. Per default staat deze op 1 en wordt 0 als je werkt met dual ocillator start-up of als de fail save monitor aan staat.

Verrek, nu je het zegt... ok, dan heb jij een raar geval...

Probeer dit eens: (Dus zonder OSCCON)

Device=16F887
@CONFIG_REQ
@__CONFIG _CONFIG1, DEBUG_OFF & LVP_OFF & FCMEN_OFF & IESO_OFF & BOR_OFF & CPD_OFF & CP_OFF & MCLRE_OFF & PWRTE_ON & WDT_OFF & INTRC_OSC_NOCLKOUT 
@__CONFIG _CONFIG2, WRT_OFF & BOR21V 

start:

High PORTD.0
DelayMS 200
Low PORTD.0
DelayMS 200
GoTo start
End

Ik kan echt geen verband zien tussen de eerste en tweede kolom overigens. Sequentieel is er een verband: de eerste kolom gaat per tien omhoog, de tweede afwisselend per acht en per twee.

Foutje van mijn kant de 2de kolom is een word adres (2 bytes)terwijl de 1ste een byte adres is.
Het loopt niet met 10 omhoog maar per 16. 10h = 16d
De 2de kolom loopt elke keer met 8 omhoog. Het verschil tussen 8h en 10h is 8

Mijne heren, ik denk het probleem gevonden te hebben.
Zoals reeds eerder gemeld had ik LVP_OFF niet in de fuse list zitten. Een verse nieuwe PIC heeft LVP altijd aan staan. Als ik het niet expliciet uit zet blijft het dus aan staan. In eerste instantie (gisteravond bij het ontdekken van de afwezigheid van die fuse) dacht ik dat dit toch niet de oplossing ging zijn aangezien LVP enkel maar te maken heeft met programmeren en niet met run mode. Vandaag ben ik verder gaan zoeken en volgens de datasheet moet er met twee dingen rekening gehouden worden als LVP gebruikt wordt. Een eerste punt is dat de interne pull-ups van RB3 uit moeten staan. In mijn code staan die juist aan! Dat is dus al zeker vragen om problemen. Een tweede punt is dat RB3/PGM niet mag zweven, maar via een pull-down weerstandje aan massa moet liggen. Wederom ligt RB3 bij mij gewoon los en er hangt een lekker lange draad van de programmer aan. Tweede geval dat vragen om problemen is.
Ik durf op dit moment dus met 85% zekerheid zeggen dat het probleem hierdoor wordt veroorzaakt. Deze middag programmeer ik LVP_OFF en dan laat ik jullie iets weten.

@benleentje: je tip om de hexcode uit te pluizen heeft uiteindelijk tot een mogelijke oplossing geleid. Anders was ik nog lang aan het zoeken, zo een klein fuseje zie je snel over het hoofd

Op 29 augustus 2009 23:14:30 schreef Henry S.:
Verrek, nu je het zegt... ok, dan heb jij een raar geval...

Natuurlijk, anders kwam ik het niet vragen

Op 29 augustus 2009 23:15:33 schreef benleentje:
Foutje van mijn kant de 2de kolom is een word adres (2 bytes)terwijl de 1ste een byte adres is.
Het loopt niet met 10 omhoog maar per 16. 10h = 16d
De 2de kolom loopt elke keer met 8 omhoog. Het verschil tussen 8h en 10h is 8

De eerste loopt wel met 10 omhoog, hetzij 10 hexadecimaal, wat inderdaad overeenkomt met 16 decimaal. Het hangt er natuurlijk heel van af in welk talstelsel je telt. Maar als je een hex stelsel hebt, vind ik niet dat je moet zeggen dat iets met 16 decimale eenheden omhoog gaat, want dan wordt het nog ingewikkelder. Vergelijk het met ik heb 5 decimaal en tel daar nu 11 binair bij op. Dan krijg ik dus 8 decimaal, maar het zou duidelijker zijn om alles in hetzelfde stelsel te houden. Dus er 3 bij optellen decimaal ipv 11 binair.
Inderdaad, als je die tweede kolom ook hexadecimaal leest is de logica terug, dan zijn het telkens stappen van 8. Je zei me eerst dat het decimaal was, dus rekende ik decimaal. Vandaar dat ik dacht dat het stappen van 8 en 2 waren.
Ik ga mij bij gelegenheid nog eens wat meer verdiepen in die hex code. Ik vind de hex code van een 68HC11 van Motorola toch ietsje makkelijker

[Bericht gewijzigd door High-Voltage op zondag 30 augustus 2009 10:56:25 (29%)]

Kijk eens naar mijn code, die had je even moeten testen.

Ik heb tot nu toe nog niets getest. Ga deze middag eerst even mn eigen typsel erin laden mét LVP_OFF opgenomen in de fuse lijst. Werkt het dan nog niet, dan vlam ik jouw code erin Henry. En als het dan nog niet werkt is het tijd voor een nieuwe PIC. Wil dat ook geen uitkomst bieden dan ga ik eens op zoek naar een echte COM poort. En als dat allemaal niet werkt, dan spring ik maar in het kanaal ofzo? Of kom ik hier nog eens zeuren
Jullie horen nog van mij.

Jup jup, het werkt, de klok loopt! Alleen werkt mijn (deel)programma niet 100% gelijk het moet, maar dat krijg ik zelf wel opgelost.
Bedankt voor het meedenken.