Feeling clever? Solve this.

[johnfitzgerald9]

Posted on October 21, 2009 at 09:22

Feeling clever? Solve this.

[johnfitzgerald9]

Posted on May 17, 2011 at 13:26

A timer overflow regularly interrupts a few times per second.

A loop waits for the interrupt. while(1) { STM_EVAL_LEDOn(LED1); __asm(''wfi''); STM_EVAL_LEDOn(LED2); STM_EVAL_LEDOff(LED1); __asm(''wfi''); STM_EVAL_LEDOff(LED2); } I expect to see the LEDs flash alternately BUT THEY DON'T. Sometimes LED1 flashes (with LED2 off) and sometimes LED2 flashes with LED1 off. Sometimes they're both off. Occasionally they alternate. Why? The code compiles as, { STM_EVAL_LEDOn(LED1); F04F0000 mov.w r0, #0 F004FAC7 bl 0x080049F0 --- main.c -- 138 -------- __asm(''wfi''); BF30 wfi --- main.c -- 139 -------- STM_EVAL_LEDOn(LED2); F04F0001 mov.w r0, #1 F004FAC2 bl 0x080049F0 --- main.c -- 140 -------- STM_EVAL_LEDOff(LED1); F04F0000 mov.w r0, #0 F004FAD6 bl 0x08004A20 --- main.c -- 141 -------- __asm(''wfi''); BF30 wfi --- main.c -- 142 -------- STM_EVAL_LEDOff(LED2); F04F0001 mov.w r0, #1 F004FAD1 bl 0x08004A20 --- main.c -- 143 -------- } E7EC b 0x0800045A OK. Looks like it only goes wrong when the debugger is attached! Without the debugger, it works as expected with regular alternate flashing. Sorry for the double posting - the server was up and down and I didn't think I'd posted.[ This message was edited by: Omniverous on 16-10-2009 13:26 ]

[jj]

Posted on May 17, 2011 at 13:26

Hi-

Don't see delays following LedOn or LedOff - so unless your running at abnormally slow speed I'm surprised that you're noting any Led activity. Re: debugger effect - is it possible that other aspects of your code read & branch debugger (shared) pins? This then may be a cause.

[johnfitzgerald9]

Posted on May 17, 2011 at 13:26

Hi,

The timing is handled by the timer interrupt. ''A timer overflow regularly interrupts a few times per second. A loop waits for the interrupt.'' The assembler instruction __asm(''wfi''); (wait for interrupt) puts the Cortex M3 to sleep, it wakes up when the timer overflows and interrupts. (interrupt on underflow update is enabled). I'm fairly sure that the JTAG debug must interfere in some way with the GPIO being written. LED control uses the bit set/reset and bit reset registers. void STM_EVAL_LEDOn(Led_TypeDef Led) { GPIO_PORT[Led]->BSRR = GPIO_PIN[Led]; } void STM_EVAL_LEDOff(Led_TypeDef Led) { GPIO_PORT[Led]->BRR = GPIO_PIN[Led]; } so there's no read / modify / write going on.

[briand.myers9]

Posted on May 17, 2011 at 13:26

The Technical Reference manual has this to say :

''The WFI instruction can complete even if no exception becomes active.'' You're using wfi for a purpose it is not designed for. I suspect that the Cortex IS being awakened when your timer overflows and interrupts - just not *only* then. I'd bet your JTAG is doing some interrupting.

[lil-vince]

Posted on May 17, 2011 at 13:26

Quote:

On 16-10-2009 at 11:58, Anonymous wrote:

OK. Looks like it only goes wrong when the debugger is attached! Without the debugger, it works as expected with regular alternate flashing. I don´t remember where I´ve seen this but WFI and WFE ionstructions can´t be used when debbugging! Read docs... 😉

[johnfitzgerald9]

Posted on May 17, 2011 at 13:26

Hi Brian,

Googled and looked. See p5-22 of ARM DDI 0337E. It looks like wfi() is used properly there. The manual refers you on to the ''ARMv7-M Architecture Reference Manual.'' and that definitely warns that debugging may interfere with wfi(). I assume that applies to the Cortex M3 version as well. wfi() IS an entry to sleep (HCLK to processor is stopped) but sleep can be exited by a pending interrupt (amongst other exceptions) hence ''Wait For Interrupt'' - that being its normal use.

[johnfitzgerald9]

Posted on May 17, 2011 at 13:26

Quote:

On 19-10-2009 at 21:01, brian.d.myers wrote: The Technical Reference manual has this to say : ''The WFI instruction can complete even if no exception becomes active.'' You're using wfi for a purpose it is not designed for. Hi Brian, Which manual, where? As far as I can see, I'm using wfi for exactly the purpose I intend. To wait in low power sleep mode until asked to do something.

[briand.myers9]

Posted on May 17, 2011 at 13:26

Google ''cortex technical reference manual'' and try the #1 result. There are other ways to find documents, but this one works pretty well, and it's fast 🙂

If you ask me, that instruction is mis-named, it's an entry to sleep, and not really a wait-for-interrupt.