Maker Pro
Maker Pro

PIC16F64 - flickering rest

E-ten

Aug 16, 2021
15
Joined
Aug 16, 2021
Messages
15
Please appreciate that I have not done any 'serious' electronics in over twentyfive years! Also note that my experience of PIC was only a couple of projects for some simple switching.

Anyway having dusted some old chips, updated my MPASMWIN (from XP!), I am now about to tear my (little left) hair out trying to understand the problem.

The problem is that when I run the program indicated below I get a flicker every 2.5 seconds or so, which looks as if the system is resetting.

I have removed a 555 timer I had incorporated in the board. No change.
I have disconnected the regulator, again fitted in the board. No change.
I have changed the oscillator from RC to XT and tried two different crystals. No change.
I have rewired MCLR and RTCC directly. Had these through 10ks because I intend to use them. No change.
I have tried three different chips with identical software. No change.

So I am beginning to thnk it is a software problem or a programming one. The programmer is one of those cheap XGecuTL866 II Plus.

Please examine the program, the hex and the read-back from the chip and let me know if you see any issues.

[Mod edit: put code in code box]
Code:
       LIST      P=16F54, R=DEC
        __FUSES   _XT_OSC & _WDT_OFF & _CP_OFF
        include   "P16F5X.inc"

;--------------------------------------------------------------------------
; Variables
;--------------------------------------------------------------------------

Ram             EQU     h'0C'
Count           EQU     Ram+1


;--------------------------------------------------------------------------
; Program Code
;--------------------------------------------------------------------------

        ORG     0
                   
   MOVLW   B'00000000'   ;Set PORTB for output
        TRIS   PORTB
 
   MOVLW      93               ;Set something to see
   MOVWF   Count

Loop   MOVF   Count, 0   ;Dump value to port to see something
   MOVWF   PORTB           ;Dump W to PORTB

   END

The Hex file is:-
:020000040000FA
:0C000000000C06005D0C2D000D02260017
:021FFE00F90FD9
:00000001FF

And the chip read-back is:-
0C00 0006 0C5D 002D 020D 0026 0FFF

Any ideas would be much appreciated.

Regards,
ep
 
Last edited by a moderator:

E-ten

Aug 16, 2021
15
Joined
Aug 16, 2021
Messages
15
As an aside, this was my first post with code and it is seriously ugly.
Perhaps someone can tell me which icon boxes the code so that it stands out.

ep
 

PETERDECO

Dec 19, 2019
239
Joined
Dec 19, 2019
Messages
239
Welcome to the forum. It sounds like it could be the Watchdog Timer timing out in a loop. Try disabling it.
 

E-ten

Aug 16, 2021
15
Joined
Aug 16, 2021
Messages
15
Watchdog Timer? Surely one only needs to deactivate it in the Fuses line?

Regards,
ep
 

PETERDECO

Dec 19, 2019
239
Joined
Dec 19, 2019
Messages
239
You can deactivate it in the configuration bits in the programming software. Usually near the Code Protect on and off.
 

E-ten

Aug 16, 2021
15
Joined
Aug 16, 2021
Messages
15
I think I already have done that - in the Fuses line as shown in the listing.
Unless there is some other setting I have not noticed?
 

E-ten

Aug 16, 2021
15
Joined
Aug 16, 2021
Messages
15
Still don't understand what is going on and what is the solution.

Is the programmer not setting the fuse _WDT_OFF ?
Or does one also have to do something else within the software?

Am afraid I do not have the experience to decode your:-
"You can deactivate it in the configuration bits in the programming software."
I thought that was what I was doing in the Fuses line.

Regards,
e10
 

E-ten

Aug 16, 2021
15
Joined
Aug 16, 2021
Messages
15
Somebody asked whether I had considered the fuses being not being configured.
Of course I hadn't!
When I tested for crystal operation I was using an old chip that I knew was crystal based since I have never used RC till now.

Further tests suggest that, if the fuses are not configured RC takes precedence although badly - I notice that pin 15 has got a nicely squared waveform at the same frequency of the oscillator rather than the expected Fosc/4.

So I now have a different question, different enough to warrant its own thread.

Regards,
ep
 
Top