Searching \ for 'Sleeping sickness!' 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/index.htm?key=sleeping+sickness
Search entire site for: 'Sleeping sickness!'.

Truncated match.
PICList Thread
'Sleeping sickness!'
1998\08\25@045610 by Clewer,Brian

flavicon
face
Hi all,

I have a project which requires low power and serial communications.  I
am able to send and receive messages to and from my pic project to my PC
at the beginning, but the problem comes when I put the pic to sleep.
When the device wakes up, I read the status of one of the ports (B) and
send the info back to my PC.  This data gets corrupted somehow before it
reaches the PC (but only about 20 percent of the time).  The pic is woken
up by a change on rb 4 to rb 7.   When the pic has sent it's info to the
PC, it goes back to sleep again.  I am using a max232 for the + and - 12V
and it is powered constantly (not though the pic).  If I cause the pic to
interrupt 2 or 3 times a second, this makes the fault worse.  For those
of you that might think I don't have the decoupleling capacitor....I do
(on both IC's).

Does anybody have any suggestions ?

Brian.

1998\08\25@182129 by Dennis Plunkett

flavicon
face
At 09:37 AM 25/08/98 PDT, you wrote:
{Quote hidden}

Humm, you don't give much information. One question I would like to ask is
which part of the message is being corrupted? If it is the last byte, then
the chances are that the PIC is being placed into sleep mode before the byte
is fully sent out-> Corruption. You may whish to check this, as often the
transmit data register empty flag is set while a byte is still being sent.
Please provide more infromation, like the type of PIC, how you're using it,
and which byte or bytes are in question

Dennis

1998\08\26@021039 by Dr. Imre Bartfai

flavicon
face
Hi,

only an idea, but based on my own experience.

If you send the serial data w/o interrupting - it is almost always the
case except if you use the Rudersdorfer approach - i. e. with delay loops
tuned to elementary bit times, it is extremely important not to allow any
IT during transmission otherwise the precious bit timing is destroyed and
garbage will be sent. In your case it is possible your program will be
IT-ed on port change.

Imre

On Tue, 25 Aug 1998, Clewer,Brian wrote:

{Quote hidden}

1998\08\26@052042 by Clewer,Brian

flavicon
face
Dennis wrote:
>>Hi all,
>>
>>I have a project which requires low power and serial communications.  I
>>am able to send and receive messages to and from my pic project to my
PC
>>at the beginning, but the problem comes when I put the pic to sleep.
>> When the device wakes up, I read the status of one of the ports (B)
and
>>send the info back to my PC.  This data gets corrupted somehow before
it
>>reaches the PC (but only about 20 percent of the time).  The pic is
woken
>>up by a change on rb 4 to rb 7.   When the pic has sent it's info to
the
>>PC, it goes back to sleep again.  I am using a max232 for the + and -
12V
>>and it is powered constantly (not though the pic).  If I cause the pic
to
{Quote hidden}

is
>which part of the message is being corrupted? If it is the last byte,
then
>the chances are that the PIC is being placed into sleep mode before the
byte
>is fully sent out-> Corruption. You may which to check this, as often
the
>transmit data register empty flag is set while a byte is still being
sent.
>Please provide more information, like the type of PIC, how you're using
it,
>and which byte or bytes are in question
>
>Dennis

I think I have found AN answer to the problem but I don't know why it
should be this way (see bottom of mail).

Ok here we go....   The PIC is a 16C74 and I am using the internal usart
I set the usart up with a subroutine at the beginning of my code like
this:

INIT_USART:     ;FOR 9600 N81 (TRANSMIT)
BSF  STATUS,RP0  ;BANK ONE
MOVLW B'00100000'  ;SET TXSTA FOR ASYNC OPERATION
MOVWF TXSTA   ;AND TO A LOW SPEED
MOVLW .05   ;SET SPBRG VALUE (9600)
MOVWF SPBRG   ; ''
BCF  STATUS,RP0  ;BANK ZERO
MOVLW B'10000000'  ;ENABLE PORT
MOVWF RCSTA   ; ''
RETURN     ;RETURN FROM ROUTINE

I am using is a   3.6864 MHz crystal.  The data corrupted is all of it
while the pic is awake .  I do check for the txreg being clear before I
send the next character.  If I transmit any amount of chars before I put
the device to sleep, they come out 100 percent OK.  If I put the device
to sleep and wake up on the port interrupt, sometimes the whole message
displayed is corrupted and the rest of the time, the message is perfect.
The fault happens about 20 percent of the wake ups.

I did some experiments last night which were:

1:)  Instead of putting the PIC to sleep, I put it round in a loop (still
having the interrupt to break the loop)
This fixed the problem.

2:) I also disabled the port by clearing the register RCSTA just before I
put the device to sleep and then enabling the port again when it wakes
up.
This also fixed the problem.

So, I can get round the problem but I wander why the usart needs to be
reset after a sleep... and I can't help thinking that someone else out
there has encountered the same bug (or feature).

Thanks

Brian.

1998\08\26@070325 by Adriano De Minicis

flavicon
face
Hi Brian,

> When the device wakes up, I read the status of one of the ports (B)
> and send the info back to my PC.  This data gets corrupted somehow
> before it reaches the PC (but only about 20 percent of the time).

Maybe the oscillator takes too much time (more than TOST=1024 clocks)
to stabilize when enabled after a wake-up from sleep.

Since the baud-rate is related to the PIC oscillator frequency, if
you send data to RS232 when the oscillator is not stable, the data
is affected by baud-rate deviations that may exceed the maximum
allowed for a error-free communication (from my memory, I remember
+/- 4% maximum).

My suggestion: add a delay routine to let the oscillator stabilize
before sending anything to the PC.

Adriano

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