Searching \ for '[PIC]: Implementing MCLR in software' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Implementing MCLR in software'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Implementing MCLR in software'
2001\12\20@235453 by Vitaliy Maksimov

picon face
Hello everyone,

I'm trying to find out if there's a way to reset a 16F73 without using
external circuitry (basically doing a RESET in software).  I need the chip
to act as if the MCLR pin was pulled LOW, when it receives the "ATZ"
command.  Can this be done without utilizing the Watchdog Timer?

Any suggestions will be greatly appreciated!

Vitaliy

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\21@013914 by Steve Faulkner

flavicon
face
I know of a board with this type of ability. It was done by external
circuitry connected to the hardware reset line and an I/O pin. When the I/O
pin pulsed the external logic was triggered to hold the CPU in reset for a
certain amount of time (lengthening the pulse sent by the I/O line). Of
course this requires that the CPU I/O line does re-trigger a reset due to a
reset. Should be ok if the I/O defaults to an input or tri-state and pull-up
is put on the line. On the board I'm thinking of the external logic was a
PLD, but it would seem to me that a flip-flop and an RC network would due
the trick of creating a pulse-stretcher if you've got the right electronics
know-how (not something I could come up with without some deep thinking).

{Original Message removed}

2001\12\21@045241 by Vitaliy Maksimov

picon face
Steve,

Thank you for your input.  I had the same idea (using an I/O pin to pull the
MCLR LOW), but I've seen a 12C508 that does [apparently] the same thing in
software, without any external hardware.  When you send an "ATZ" command to
the chip, it displays a welcome message (like it was just turned on), and
all of the registers are reset.  I just want the circuit to be less
cluttered..

Vitaliy

{Original Message removed}

2001\12\21@081057 by Drew Vassallo

picon face
This has been discussed a number of times in the past year or so.  Search
the PICLIST message archives for "reset in software".

Also, check the code software archives, there may be snippets available.

--Andrew

_________________________________________________________________
Join the world s largest e-mail service with MSN Hotmail.
http://www.hotmail.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\12\21@100311 by Bob Ammerman

picon face
When you see the ATZ just jump to location zero. This will rerun your
initialization code and act pretty much like MCLR was pulled down.

Bob Ammerman
RAm Systems

{Original Message removed}

2001\12\21@155352 by Fabio Pereira

flavicon
face
> When you see the ATZ just jump to location zero. This will rerun your
> initialization code and act pretty much like MCLR was pulled down.
>
> Bob Ammerman
> RAm Systems
>
Yeah but in a POR many regs (SFR) are set to a default state (as defined by
Microchip), and that will not be true for a initialization routine (well
maybe if the code cover all SFRs ..... ;-) )

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2001\12\21@162310 by Drew Vassallo

picon face
>Yeah but in a POR many regs (SFR) are set to a default state (as defined by
>Microchip), and that will not be true for a initialization routine

Note that MCLR* pulled low is NOT equal to a POR and the registers in that
case will be different than those seen with a POR.

As I said, there have been a few threads on this topic... please search
through the PICLIST message archives for details.  I know people have
suggested which registers should be "corrected" to best accomplish a
software reset.

--Andrew



_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\12\21@172828 by Vitaliy Maksimov

picon face
Bob -

I will certainly try that, it looks like I'll just have to add a couple of
lines of code to reset the I/O pins.  Thank you very much!

Drew -

I'm just beginning to understand the PIC MCU's, and apologize for asking
dumb questions.  I did search the PICLIST  for "reset in software", and the
only thing I found was a program to reset the 286-based PC.  I also read the
datasheet, searched the internet and discussed the problem with my friend.
In the future, I will keep trying to go through the above steps before
posting to this mailing list.  Please bear with me, I will get better.  :-)

Vitaliy


{Original Message removed}

2001\12\21@201621 by Bob Ammerman

picon face
----- Original Message -----
From: "Fabio Pereira" <.....fabioKILLspamspam.....PP.ADV.BR>
To: <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Friday, December 21, 2001 12:37 PM
Subject: Re: [PIC]: Implementing MCLR in software


> > When you see the ATZ just jump to location zero. This will rerun your
> > initialization code and act pretty much like MCLR was pulled down.
> >
> > Bob Ammerman
> > RAm Systems
> >
> Yeah but in a POR many regs (SFR) are set to a default state (as defined
by
> Microchip), and that will not be true for a initialization routine (well
> maybe if the code cover all SFRs ..... ;-) )

Yep, that's pretty much what you have to do.

Bob Ammerman
RAm Systems

> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
>
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\12\22@054930 by Peter L. Peres

picon face
> When you see the ATZ just jump to location zero. This will rerun your
> initialization code and act pretty much like MCLR was pulled down.

Yes but that does not pop the subroutine stack, and that's one of the
important things MCLR does. Delierately allowing the WDT to trip is better
imho. Uses no external pins too.

Peter

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\12\22@082044 by Michael Coop

flavicon
face
How about letting the WDT time out...
That to all intents and purposes is an MCLR

-----Original Message-----
From: pic microcontroller discussion list
[RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU]On Behalf Of Vitaliy Maksimov
Sent: Friday, 21 December 2001 19:27
To: spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU
Subject: Re: [PIC]: Implementing MCLR in software


Steve,

Thank you for your input.  I had the same idea (using an I/O pin to pull the
MCLR LOW), but I've seen a 12C508 that does [apparently] the same thing in
software, without any external hardware.  When you send an "ATZ" command to
the chip, it displays a welcome message (like it was just turned on), and
all of the registers are reset.  I just want the circuit to be less
cluttered..

Vitaliy

----- Original Message -----
From: Steve Faulkner <TakeThisOuTSteveEraseMEspamspam_OUTFAULKNER.NET>
To: <RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: 12.20.2001 11:15 PM
Subject: Re: [PIC]: Implementing MCLR in software


> I know of a board with this type of ability. It was done by external
> circuitry connected to the hardware reset line and an I/O pin. When the
I/O
> pin pulsed the external logic was triggered to hold the CPU in reset for a
> certain amount of time (lengthening the pulse sent by the I/O line). Of
> course this requires that the CPU I/O line does re-trigger a reset due to
a
> reset. Should be ok if the I/O defaults to an input or tri-state and
pull-up
> is put on the line. On the board I'm thinking of the external logic was a
> PLD, but it would seem to me that a flip-flop and an RC network would due
> the trick of creating a pulse-stretcher if you've got the right
electronics
{Quote hidden}

chip
{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu


2001\12\22@093928 by Bob Ammerman

picon face
You don't have to worry about the subroutine stack because it is circular.
So any leftovers will just get pushed out of the way (ie: overwritten) as
new calls are made.

Bob Ammerman
RAm Systems


{Original Message removed}

2001\12\22@113105 by dpharris

picon face
Who cares what's on the stack after a 'reset'?
D

"Peter L. Peres" wrote:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\12\22@165142 by uter van ooijen & floortje hanneman

picon face
> Yes but that does not pop the subroutine stack, and that's one of the
> important things MCLR does.

I do not think you need to pop the subroutine stack. Can you make a program
that behaves difefrently when the stack is not 'poped' (whatever that should
mean in the contect of a PIC!).

Wouter van Ooijen

Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler for PIC uC's:  http://www.voti.nl/jal
PICs kopen? http://www.voti.nl/shop

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspamspamspam_OUTmitvma.mit.edu


2001\12\23@021934 by Peter L. Peres

picon face
> circular

Bob, are you sure this is true for all PICs ? (esp 12 and 14 bit cores) ?

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\12\23@034559 by uter van ooijen & floortje hanneman

picon face
> Bob, are you sure this is true for all PICs ? (esp 12 and 14 bit cores) ?

The description of the stack in all uChip documentation I have seen is the
same: push throws the oldest entry into never-never, pop duplicates the
oldest entry. Hence the number of entries always stays the same. Note that
this is not exactly the same as a cyclic stack, but I'm not sure you can
make a program that depends on the difference.

Wouter van Ooijen

Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler for PIC uC's:  http://www.voti.nl/jal
PICs kopen? http://www.voti.nl/shop

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\12\23@150028 by Peter L. Peres

picon face
> Who cares what's on the stack after a 'reset'?
> D

Since the SP does not get reset (Bob says it does not matter since it is
circular), you do, since you may run out of free stack sooner than you
plan. F.ex. if the stack is not circular and the soft reset occurs in a
subr. nested at stack level 2 and the soft reset does not clear the stack
(it can't, on a 12 or 14 bit core pic) then you only have 4 levels of
stack left. This is almost certainly not enough. Of course the point is
moot if the stack is circular but my ompression of the datasheet programs
was, that it is not.

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\12\23@173913 by andy n1yew

picon face
The stack is circular.

andy
----- Original Message -----
From: "Peter L. Peres" <spamBeGoneplpSTOPspamspamEraseMEACTCOM.CO.IL>
To: <KILLspamPICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Sunday, December 23, 2001 1:33 AM
Subject: Re: [PIC]: Implementing MCLR in software


{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\12\25@041805 by Bob Ammerman

picon face
The stack is circular for all PICs that I am aware of (certainly 12C and
16C/16F, haven't dealt with 17C in a while), except the 18C.

I know that the stack on the 18C/18F is _NOT_ circular. But the 18C has an
explicit stack pointer register that you can initialize.

Bob  Ammerman
RAm Systems


{Original Message removed}

2001\12\25@122150 by Peter L. Peres

picon face
Hi Wouter, thanks for the ideas, are you trying to say that something like
this will work ?:

main:
 bsf STATUS,RP0
 clrf TRISA
 bcf STATUS,RP0

 call Thesub           ; call it and then fall through into it

Thesub:
 movlw 0x01
 xorwf PORTA,f
 retlw 0               ; this should jump to Thesub according to your
                       ; description (pop keeps popping the last value)

BTW I bet a small sum of money that most simulators do not follow this
functionality. As to usefullness ? Every merchandise has its buyer [tm].

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\25@130412 by Morgan Olsson

picon face
Working reset code:
techref.massmind.org/techref/microchip/hrdrstsw.htm
/Morgan

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\25@130828 by Bob Ammerman

picon face
----- Original Message -----
From: "Peter L. Peres" <EraseMEplpspamEraseMEACTCOM.CO.IL>
To: <@spam@PICLIST@spam@spamspam_OUTMITVMA.MIT.EDU>
Sent: Monday, December 24, 2001 11:51 AM
Subject: Re: [PIC]: Implementing MCLR in software


{Quote hidden}

Peter,

This sample will NOT work because only one entry on the stack has been
initialized
to contain the return address that gets you back to 'Thesub'.

This ugly code would work however (assuming interrupts are off):

main:
   bsf    STATUS,RP0
   clrf    TRISA
   bcf    STATUS,RP0
   clrf    COUNTER
Docall:
   call    Thesub
Thesub:
   btfsc    COUNTER,5    ; Have we already filled the stack?
   goto     CountDone       ; Yes
   incf       COUNTER      ; No, count one more
   goto      Docall              ; ...and push another level
CountDone:
   movlw    1
   xorwf     PORTA,F
   retlw      0                    ; will return to ''Thesub' forever


   incfsz    COUNTER,F    ; Bump the counter
   goto      Docall               ; D

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\25@213057 by uter van ooijen & floortje hanneman

picon face
> main:
>   bsf STATUS,RP0
>   clrf TRISA
>   bcf STATUS,RP0
>
>   call Thesub           ; call it and then fall through into it
>
> Thesub:
>   movlw 0x01
>   xorwf PORTA,f
>   retlw 0               ; this should jump to Thesub according to your
>                         ; description (pop keeps popping the last value)

I do not see how this construct depends on the (you assume a 12-bit core? =>
2-entry) stack preserving its deepest value. The call pushes 'Thesub' and
jumps to it, stack is now (left is top)
'Thesub', X
the PC executes the subroutine, pops 'Thesub' and returns. stack is now
X, X
execution continues at 'Thesub' (again), at the retlw X is popped an the PIC
goes to never-never.

BTW the above (calling a sub that follows the call) can be a usefull
construct, I used it in the Wisp firmware (or at least it was available in
my include files, I can not find an actual use of it):

; convert w to two hex values in w, high nibble first
convert_w_to_hl_hex macro
local same = 1
local w = 0
cblock
 _file_1#v($)
endc
local temp = _file_1#v($)
local do_it
movwf temp
call do_it
swapf temp, same
do_it
swapf temp, w
andlw H'0F'
endm

;use
send_w_hl
  convert_w_to_hl_hex
  send_w
  ret

Wouter van Ooijen

Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler for PIC uC's:  http://www.voti.nl/jal
PICs kopen? http://www.voti.nl/shop

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\12\26@121106 by Scott Dattalo

face
flavicon
face
On Tue, 25 Dec 2001, Bob Ammerman wrote:

> ----- Original Message -----
> To: <spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU>
> Sent: Monday, December 24, 2001 11:51 AM
> Subject: Re: [PIC]: Implementing MCLR in software
>
>
<snip>

{Quote hidden}

<snip>

We talked about stack priming before (in the context of RTOS'). I just
whipped together this routine and tested it with gpsim (Peter, you'd lose
a small sum of money if you were betting getting agains gpsim).

       list    p=16f84

       ;; The purpose of this program is to test gpsim's capability to
simulate
       ;; the PIC's stack.
       ;;
       ;;   Start gpsim:
       ;;   $ gpsim
       ;;   then load the Startup command file 'stack_test.stc':
       ;;   gpsim> load c stack_test.stc
       ;;
       ;;    OR
       ;;
       ;;   invoke gpsim with the command file
       ;;   $ gpsim -c stack_test.stc
       ;;
       ;;    OR
       ;;
       ;;   invoke the simualtion from the Makefile:
       ;;   make sim

       ;; In all cases, the stimulus file will load the simulation
       ;; file and create the stimuli. In the Makefile case, the
       ;; simulation file will be (re)created if the .asm has been
       ;; been changed.
       ;;
       ;;



include "p16f84.inc"

 cblock  0x20

       temp1
       temp2
       temp3
 endc

       org     0
       goto    start

       org     4
start

init_tasks
       goto    Task_0_init
init_done


       return

       goto   $  ; never reached

Task_0_init:
       call    Task_1_init
Task_0:
       return

Task_1_init:
       call    Task_2_init
Task_1:
       return

Task_2_init:
       call    Task_3_init
Task_2:
       return

Task_3_init:
       call    Task_4_init
Task_3:
       return

Task_4_init:
       call    Task_5_init
Task_4:
       return

Task_5_init:
       call    Task_6_init
Task_5:
       return

Task_6_init:
       call    Task_7_init
Task_6:
       return

Task_7_init:
       call    init_done
Task_7:
       return

       end


-----
This code loads the stack with the starting addresses of each "task". A
"task switch" occurs by simply returning. As shown, this is hardly useful.
However, it's possible to retain one level of stack state per task. In
other words, as shown the code above will begin executing at the begining
of each task. However, if a call is made with in the task (just one call,
mind you), then the return address can be modified. E.g. Here's Task 1
modified to have two different exit points.


Task_1_init:
       call    Task_2_init
Task_1:

       btfsc   portb,0
       goto    t1b
       call    $+1        ; this changes task 1's exit
t1a
       movlw   2
       return
t1b
       movlw   3
       return


-----

As said before, while interesting I don't see much usefulness for this
kind of code.

Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservspam_OUTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\12\26@154119 by Peter L. Peres

picon face
Wouter, Robert, thanks for the examples.

I was under the impression that the stack is not circular, but 'flooring',
i.e. it decrements to 0 on pop and stays 0. Therefore the last pushed
address will be returned when popping again (this would have made my code
snippet work). I understand that this is wrong.

thanks,

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistserv.....spamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...