Second interrupt caused wake-up

hoteloskar · Joined: 01 Nov 2006 Posts: 3

I'm using a 16LF876A where the internal USART is already used to feed an MP3 chip. But because of needing a further serial character input with interrupt capability I am using RB0 as a serial input.

Everything works fine, except when the sleep instruction is executed. Just every second (2.) incoming character will cause a wake-up. Also the ISR will not be executed at the first character, only at the second (2.) character.

Here is the code:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

hoteloskar · Joined: 01 Nov 2006 Posts: 3

Thanks for your very fast answer.
The link you provided makes it a bit clearer, but not completely.

When receiving the first character the PIC must change the state internaly
in any way. Because the second character will be sent 10 or more seconds later and is received (printed) immediately.

I also reduced the baud rate from 9600 to 300. This caused also a character printed immediately. But only garbage, because some bits from the character are lost.

The behaviour of the PIC for me looks like a human wake-up. At a first noise in the morning you will get from deep sleep into a light sleep and at the second noise you will wake-up completely.

Reagards, Hans

Ttelmah · Guest

The chip should be 'starting to wake' straight away, but won't be able to actually clock data in, until the master oscillator is up to speed. So the first character, is always going to either be garbage, or be missed completely. The chip will have woken up, but the data will be scrap, unless you run the chip from an external clock.
In your 'human' analogy, it is as if somebody starts talking into your ear, and wakes you. Though the noise wakes you up, you would not be able to say 'what they said'.

Best Wishes

Ttelmah · Guest

As an 'ongoing comment', to explain what you are seeing, On the first falling edge of the first character, the chip starts to wake up. There is a pause, while the oscillator starts, and then the code jumps immediately to the ISR. The first thing you do in the ISR, is call 'getc'. Now on the software serial, this checks to see if the input line is 'low', and only if it is, does it start to receive the character. Otherwise it waits. Because of the time that has passed, the character has been missed, so the code sits waiting in the ISR. Only when the second character arrives, is the 'low' seen, and this is then received.
When you switched to using a much slower rate, the whole character had not been missed, but the start bit (or most of it), had been missed. Hence the reception starts at the next 'low' in the character, resulting in garbage.
If you code the ISR like this, you will see what is happening:

hoteloskar · Joined: 01 Nov 2006 Posts: 3

Oh yes, thats it is. Very Happy

Thank you very much for your great explanation. The hang-up in 'getc'
is the main problem.
I still was thinking over your previous reply, because it did not cover the whole problem. But now you hit it exactly.
I still was wondering why second character apears immediatly and correct.
Now I know it.

Thank you very much once again, you are a real professional Exclamation

Best Regards

Hans