cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 wakeup from deepsleep

simonkallweit9
Associate II
Posted on February 10, 2009 at 23:04

STM32 wakeup from deepsleep

5 REPLIES 5
simonkallweit9
Associate II
Posted on May 17, 2011 at 12:58

Thanks for the hint. Unfortunately holding down nRST does not seem to work here. Could be a problem of OpenOCD. I also managed to switch the boot memory to 'Embedded SRAM' which did work (at least my test software didn't start up) but I was unable to probe and erase the internal flash, which is rather strange.

Hmm ...

simonkallweit9
Associate II
Posted on May 17, 2011 at 12:58

During testing the deepsleep feature, it looks like I have bricked one of my boards. It's a custom design and the boot pins are hardwired, so it's not easy to change boot memory. The software (test) puts the board into deepsleep, and it does not wakeup. I'm currently using OpenOCD and I'm not able to wakeup the board and flash a new software. The time-window before entering the sleep mode is too tight to intercept with the JTAG. Is there anything I can do to recover?

This is the current testing code (using eCos):

Code:

// Make sure we are atomic here

HAL_DISABLE_INTERRUPTS(old);

cyg_scheduler_lock();

// Reset the wakeup circuit (flipflop)

CYGHWR_HAL_STM32_GPIO_OUT(CYGHWR_RESET_WAKEUP, 0);

hal_delay_us(1000);

CYGHWR_HAL_STM32_GPIO_OUT(CYGHWR_RESET_WAKEUP, 1);

// Clear pending EXTI interrupts

HAL_WRITE_UINT32(exti + CYGHWR_HAL_STM32_EXTI_PR, 0xffffffff);

// Configure the voltage regulator to low-power-deep-sleep

HAL_READ_UINT32(pwr + CYGHWR_HAL_STM32_PWR_CR, cr);

cr &= ~(CYGHWR_HAL_STM32_PWR_CR_PDDS);

cr |= CYGHWR_HAL_STM32_PWR_CR_LPDS;

HAL_WRITE_UINT32(pwr + CYGHWR_HAL_STM32_PWR_CR, cr);

// Set deep-sleep in the Cortex-M3 core

HAL_READ_UINT32(nvic + CYGARC_REG_NVIC_SCR, scr);

scr |= CYGARC_REG_NVIC_SCR_DEEPSLEEP;

HAL_WRITE_UINT32(nvic + CYGARC_REG_NVIC_SCR, scr);

asm (''wfi'');

Any ideas?

Best regards,

Simon

relaxe
Associate II
Posted on May 17, 2011 at 12:58

I use IAR, and had a similar problem :-]

Wire a switch to the MCU nRESET.

Hold the MCU in reset while doing a normal programming

When trying to access the chip, the JTAG will fail and retry for a number of times.

You have to release reset during that window.

Hope there is enough time, or that there is a better way!

-Relaxe

simonkallweit9
Associate II
Posted on May 17, 2011 at 12:58

Just wanted to let you know that I solved the issue by setting the BOOT0 pin to high, so the board doesn't boot from internal flash. I still think there should be a simpler way of doing that, but at least I can use my board again.

Simon

ben4
Associate II
Posted on May 17, 2011 at 12:58

Interesting -- I've just run into exactly the same issue (and locked up several boards!), and only tracked it down to the WFI instruction today. It seems WFI and JTAG aren't very good friends.

I found further that this is documented reasonably well in the STM32 reference manual. You can keep debug (JTAG) working alongside WFI by setting the DBG_SLEEP bit in the DBGMCU_CR register.

However, though this helps majorly, I've found it still sometimes takes a few tries to connect to a board via JTAG, presumably because I'm not reconfiguring the clock controller when exiting sleep mode (as the DBG_SLEEP docs in the reference manual hint I'd need to).

So we're not using WFI and low power mode for now, till we can be bothered to fix the remaining issues. 🙂