18F14K22 simulatie werk wel, in het echt niet

Niks...

ANSEL stukjes erbij gezet zoals diebobo aangeeft, zelfde resultaat.
GOTO loop veranderd in een WHILE loop zoals in het programma van Arco, zelfde resultaat.
Alles in de loop gezet, dus ook de OSCCON en LAT zoals bij het programma van Arco, zelfde resultaat.
DelayMS veranderd in uS, om te kijken of de clock toch verkeerd staat, zelfde resultaat.
(Heeft zeker 10 minuten aan gestaan, maar de 2e LED gaat echt niet in Toggle...)

Alleen de ene LED gaat aan, dus het programma loopt wel, maar alles na de delay doet niks.
Haal ik de eerste delay weg, zodat het programma bij de Toggle komt, gaat ook de 2e LED aan, maar niet meer uit...

Zou bijna de software zelf gaan verdenken, ondanks dat ik geen errors krijg met compilen, en geen errors met programmeren ?

In the beginning there was nothing, but even that exploded

Op 1 januari 2017 10:17:32 schreef diebobo:
Ik kan je maar beperkt helpen op het moment.. Maar mijn Config die ik gebruik voor 64mHz met de INTERNE osc.

pic basic code:

Xtal = 64   ' = 16 mhz interne OSC * 4 PLL

Ik ben niet bekend met PICBASIC maar is het niet zo dat je XTAL 64 moet schrijven ipv XTAL = 64 ??

Op 3 januari 2017 08:36:07 schreef SkalTura:
Haal ik de eerste delay weg, zodat het programma bij de Toggle komt, gaat ook de 2e LED aan, maar niet meer uit...

En als je de tweede delay OOK weghaalt, gaat C4 dan als een bezetene toggle'n? (Controleren met oscilloscoop want met het oog zul je het misschien niet zien, of wellicht waarneembaar door de mindere intensiteit van een aangesloten LED.)

[Bericht gewijzigd door Jochem op dinsdag 3 januari 2017 08:55:06 (38%)

If you want to succeed, double your failure rate.

.

[Bericht gewijzigd door Jochem op dinsdag 3 januari 2017 08:55:23 (89%)

If you want to succeed, double your failure rate.

Op 3 januari 2017 08:49:21 schreef Jochem:
En als je de tweede delay OOK weghaalt, gaat C4 dan als een bezetene toggle'n?

Nee, gaat alleen aan. Gaat niet terug in de loop.

In the beginning there was nothing, but even that exploded
diebobo

Golden Member

Wat kan je vertellen over je hardware ? Voeding, ontkoppelcondensators etc.. Foto'tje (scherp) ?

Arco

Special Member

Aangezien mijn hexfile het wel doet, zal het niet aan de hardware liggen...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Op 3 januari 2017 09:56:02 schreef diebobo:
Wat kan je vertellen over je hardware ? Voeding, ontkoppelcondensators etc.. Foto'tje (scherp) ?

Zit een 100nF en 10uF capje over de PIC. Voeding is 5,05v gemeten met 1A belasting.

Kan bijna niet aan de hardware liggen, een 16F628A met Toggle doet het wel gewoon (nadat ik de juiste file had geladen).
En zoals Arco al zei, zijn HEX file werkt wel.

Moet bijna wel aan mijn software liggen.
Misschien heeft een of andere update van Windows iets om zeep geholpen.

Ga alles er af gooien en opnieuw installeren, mogelijk dat dit het probleem gaat verhelpen, hoewel andere PICjes wel gewoon werken na programmeren...
Maar je weet het nooit met Windows natuurlijk.

[Bericht gewijzigd door SkalTura op dinsdag 3 januari 2017 12:43:14 (31%)

In the beginning there was nothing, but even that exploded
Arco

Special Member

Kan bijna niet aan de hardware liggen, een 16F628A met Toggle doet het wel gewoon

Dat zegt natuurlijk niets, het zijn twee totaal verschillende processors.
Maar zoals reeds gezegd, aangezien de hexfile die ik heb gepost wel werkte bij jou, zal de hardware niet de oorzaak zijn...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Op 3 januari 2017 12:40:43 schreef SkalTura:
Misschien heeft een of andere update van Windows iets om zeep geholpen.

Ga alles er af gooien en opnieuw installeren, mogelijk dat dit het probleem gaat verhelpen, hoewel andere PICjes wel gewoon werken na programmeren...
Maar je weet het nooit met Windows natuurlijk.

Wat heeft het in hemelsnaam met Windows te maken?

Je kunt Arco z'n HEX-file programmeren en probleemloos laten werken, dat heb je al aangegeven. Dat is het enige dat met drivers (en dus in een uiterst geval met een Windows-update) te maken kan hebben.

Verder compileert je programma zonder warnings of errors (neem ik aan???) en kun je er een HEX-file van maken.

Allemaal niks met Windows van doen.

Ik verdenk nog steeds een configuratiefout of iets met PIC-basic. Maar ik weet niks van PIC-basic dus ik kan het niet zien. Heeft iemand al eens geprobeerd om JOUW code in ZIJN PIC18F14K22 te zetten?

Nog een andere vraag: weet je ZEKER dat jouw programmer deze chip ondersteunt? De PicKit2 bijvoorbeeld wil deze chip niet goed programmeren lees ik op internet en dan hebben we het dus over een programmer van Microchip zelf! *edit: niet alles van internet geloven

Ik weet dat je de HEX-file van Arco wel hebt geprobeerd, maar was dat niet stiekem met een andere programmer? Of doe je iets anders voor het zetten van de config/fuses? Je chain is me niet helemaal duidelijk (wat vast ook komt doordat ik met PICbasic en jouw programmer beiden geen ervaring heb).

If you want to succeed, double your failure rate.

zet uw programmer de config file wel in uw pic?
fout lijkt een beetje alsof de WDT timer niet wordt gereset of een overflow in uw programma of een fout in de delay routine.
Etienne

Nog even wat gelezen.. het schijnt dat proton de CONFIG4L bit 7 niet zet, terwijl hij dat wel zou moeten doen.

Probeer eens te compileren, en daarna (voor het programmeren) handmatig die bit te setten.

*edit:
of een andere oplossing, de config-bits handmatig te zetten:

pic basic code:

@ CONFIG_REQ = 0 ; Disable the compiler's configuration setup 
Asm- 
' 
' Add custom values for fuses 
' 
__config config1h, 0xE8 
__config config2l, 0x19 
__config config2h, 0x1E 
__config config3h, 0x00 
__config config4l, 0x81 
__config config5l, 0x03 
__config config5h, 0xC0 
__config config6l, 0x03 
__config config6h, 0xE0 
__config config7l, 0x03 
__config config7h, 0x40 
Endasm-

De 0x81 van config4l doet die bit 7, de rest zul je wellicht aan willen passen aan jouw wensen.

Wel vreemd dat ik bovenstaande info uit topics van 2010 pluk en Proton dat nog niet heeft verbeterd. Of gebruik je een oude versie van de compiler??
edit2:
Misschien kan de compiler voor deze PIC inmiddels gewoon overweg met debug = OFF tussen Config_Start en Config_End. Het lijkt me de korste weg om dat als eerste eens te proberen.

If you want to succeed, double your failure rate.
Arco

Special Member

Zal niet helpen. CONFIG4L bit 7 is 'unimplemented' volgens datasheet. In de hexfile kun je zien welke configbits er wel/niet worden geset...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Dat is het hele punt: de datasheet is onduidelijk maar die bit is wel geïmplementeerd en heeft betrekking op 'debug mode' en veroorzaakt het gedrag dat de pic 'stopt'.

Ik heb de webpagina's al weggeklikt, als er belangstelling voor is zal ik even proberen om mijn bronnen terug te zoeken (want ik ben geenszins een proton kenner hoor, ik kopieer alleen wat ik heb gevonden via Google).

Probleem dat heel erg lijkt op de ervaring van TS:
http://www.protonbasic.co.uk/showthread.php/59795-Problem-with-PIC18F1….

Vervolg van die persoon zijn onderzoek waarbij die config4L bit7 aan het licht komt:
http://www.protonbasic.co.uk/showthread.php/60842-18F13K22-and-PIKIT2-…

[Bericht gewijzigd door Jochem op dinsdag 3 januari 2017 13:56:00 (29%)

If you want to succeed, double your failure rate.

Probeer het eerst eens met alleen intrc op 8 MHz en zonder pll

Verder heb ik je code in PicBasic geïmporteerd en de configuratie met de FuseConfigurator gedaan
;-------------------------------------------------------------------------------
;**** Added by Fuse Configurator ****
; Use the Fuse Configurator plug-in to change these settings

Device = 18F14K22

Config_Start
FOSC = IRC ;Internal RC oscillator
PLLEN = On ;Oscillator multiplied by 4
PCLKEN = On ;Primary clock enabled
FCMEN = OFF ;Fail-Safe Clock Monitor disabled
IESO = OFF ;Oscillator Switchover mode disabled
PWRTEN = OFF ;PWRT disabled
BOREN = OFF ;Brown-out Reset disabled in hardware and software
BORV = 19 ;VBOR set to 1.9 V nominal
WDTEN = OFF ;WDT is controlled by SWDTEN bit of the WDTCON register
WDTPS = 32768 ;1:32768
HFOFST = On ;HFINTOSC starts clocking the CPU without waiting for the oscillator to stablize.
MCLRE = On ;MCLR pin enabled, RA3 input pin disabled
STVREN = On ;Stack full/underflow will cause Reset
LVP = OFF ;Single-Supply ICSP disabled
BBSIZ = OFF ;1kW boot block size
XINST = OFF ;Instruction set extension and Indexed Addressing mode disabled (Legacy mode)
Debug = OFF ;Background debugger disabled, RA0 and RA1 configured as general purpose I/O pins
Cp0 = OFF ;Block 0 not code-protected
CP1 = OFF ;Block 1 not code-protected
CPB = OFF ;Boot block not code-protected
CPD = OFF ;Data EEPROM not code-protected
WRT0 = OFF ;Block 0 not write-protected
WRT1 = OFF ;Block 1 not write-protected
WRTC = OFF ;Configuration registers not write-protected
WRTB = OFF ;Boot block not write-protected
WRTD = OFF ;Data EEPROM not write-protected
EBTR0 = OFF ;Block 0 not protected from table reads executed in other blocks
EBTR1 = OFF ;Block 1 not protected from table reads executed in other blocks
EBTRB = OFF ;Boot block not protected from table reads executed in other blocks
Config_End

;**** End of Fuse Configurator Settings ****
;-------------------------------------------------------------------------------
De belangrijkste verschillen:
- Debug = OFF
- PCLKEN = On

Ik heb het programma met MPLab SIM uitgeprobeerd en die had op een gegeven moment geen zin meer.
Ik heb toen het label 'loop:' vervangen door 'noggus:' en de bijbehorende goto van 'goto loop' door 'goto noggus'.
Probleemloos.
Je zou zomaar eens een rare PicBasic anomalie te pakken kunnen hebben. 'loop' is geen protected keyword, dus daar zal het niet aan liggen.
Welke versie van de compiler gebruik je (ik het het uitgeprobeerd met 3.5.8.6.)? Ik kan het wel 'voor het echie' uittesten, maar dan moet ik eerst even een printje fabrieken. Kan dus even duren.

[Bericht gewijzigd door hadv op dinsdag 3 januari 2017 14:39:31 (12%)

Just find out what you like and let it kill you

Kijk, komt toch die debug=off om de hoek...

If you want to succeed, double your failure rate.
Arco

Special Member

MCLRE wel beter op OFF zetten... (dan werkt 't altijd)
PUT (Power-Up Timer, PWRTEN), kun je ook beter aanzetten, kan de controller zich even 'acclimatiseren'... ;)

Hebben trouwens meer mensen hier last van?:
Bij posten van een antwoord 'hangt' de boel soms met een wit scherm. Bij drukken F5 ververst het scherm en is alle ingetypte tekst weg... :(

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Ja, niet alleen bij het posten.. CO heeft vandaag de hele dag al dat hij soms een keer een witte pagina geeft als response. Ik heb in dit oudere topic inmiddels melding gemaakt.

Als je Firefox gebruikt en niet F5 maar back doet dan komt de getypte tekst gewoon terug.

If you want to succeed, double your failure rate.

Het probleem zit in de 'debug' fuse. Deze MOET op OFF staan.
Het programma loopt in het echt, een constant rood brandend ledje en een knipperend groen ledje.
MCLRE heb ik op OFF gezet.

Just find out what you like and let it kill you

Op 3 januari 2017 13:13:20 schreef Jochem:
Wat heeft het in hemelsnaam met Windows te maken?

Blijkbaar alles !!

Na het opnieuw installeren van Proton gaf deze aan dat de dongle niet aanwezig was. Deze eruit gehaald en opnieuw erin gestoken, en het werkt nu prima.
Zowel het test programmatje, als het originele programma doen het gewoon.
Dus Windows heeft blijkbaar met een of andere update de dongle drive om zeep geholpen ofzo.

Wel raar dat ik er met andere PICjes geen last van gehad heb...

In the beginning there was nothing, but even that exploded

Voor het (her)installeren en geklooi met de dongle moet je op het forum op de site van Crownhill zoeken.

Heeft niets!! met Windows te maken maar met de enigszins instabiele werking van de dongle na (her)installatie.

Just find out what you like and let it kill you

Op 3 januari 2017 16:33:18 schreef SkalTura:
Blijkbaar alles !!

Er zijn altijd mensen die graag Windows de schuld geven van alles dat ze niet zelf kunnen verklaren.

Dus Windows heeft blijkbaar met een of andere update de dongle drive om zeep geholpen ofzo.

"Dus"? Ik snap nog steeds niet hoe je de conclusie weet te trekken (en jij zelf aan de "ofzo" te zien ook niet).

If you want to succeed, double your failure rate.
Arco

Special Member

Als er iets mis gaat doen we dat meestal zelf. (en dan geeft men vaak Windows maar de schuld)... :)
Meestal een geval van een brakke driver voor de dongle die niet erg netjes geschreven is...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com