Re: [avr-chat] why does ISR not always seem to run on wake from sleep?

[Britton Kerin]

On Mon, Nov 7, 2016 at 10:58 PM, Rolf Pfister <address@hidden> wrote:
> Am 08.11.2016 um 01:56 schrieb Britton Kerin:
>>
>> #define BLINK_PB5_LED_FOREVER(period_ms) \
>>   do {                                   \
>>     for ( ; ; ) {                        \
>>       PORTB |= _BV (PORTB5);             \
>>       _delay_ms (period_ms / 2.0);       \
>>       PORTB &= ~(_BV (PORTB5));          \
>>       _delay_ms (period_ms / 2.0);       \
>>     }                                    \
>>   } while ( 0 );
>>
>
> This do while dont make any sense, with while(0) it will
> run only once. while(1) would do it forever.
> Anyway the for(;;) will do the loop for ever.

Yes, it's just a syntactic habit for functionesque macros,
you're right that the outer do-while is pointless here

>>
>>   while ( 1 ) {
>>     set_sleep_mode (SLEEP_MODE_IDLE);
>>     sleep_enable ();
>>     sei ();
>>     sleep_cpu ();
>>     sleep_disable ();
>>     cli ();
>>
>>     if ( inry ) {
>>       BLINK_PB5_LED_FOREVER (100.42);   // Never seems to happen
>>     }
>>
>>     if ( ! got_pbpci ) {
>>       BLINK_PB5_LED_FOREVER (200.42);   // Always happend eventually
>>     }
>>     else {
>>       got_pbpci = 0;
>>     }
>>   }
>
>
> I think after reaching BLINK_PB5_LED_FOREVER it will never again
> go to sleep mode. And interrupts will also not happen because
> of the cli().

Yes, those are intended as traps to show when we've ended up in
what should be an impossible situation (according to the datasheet).
The program isn't supposed to recover once it gets to them.

The problem is it should never get to them in the first place, but it does.

Having thought about this more I believe the root of the problem is
shown in Fig-1 of the ATMega328P datasheet.  When sleeping the
clock is stopped, and when idle I think clk is shut off to the input
circuit of 17-1, but in either case pin change detection can occur,
so obviously it isn't happening due to that circuit.  So wake up can
occur independently, and the only question is whether that circuit
always triggers an interrupt correctly once the clock is going.  I
don't see how it possibly can, because the state of the input that
drives the XOR cannot be known.  So the datasheet is wrong and
an ISR is not guaranteed in this situation.  It has a caveat for
level-triggered interrupts on wake, and it should have one for
this situation as well.

Britton


>
> Rolf
>
>
> _______________________________________________
> AVR-chat mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/avr-chat