This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Low Power Test Locks out Debugger

I was running The Low Power FreeRTOS example on a STM32F446 Eval board. The operation of the
example is to (Cortex M4) :

This example creates two threads.

+ A Rx thread that blocks on a queue to wait for data, blinking LED each time data is received (turning it on and then off again) before returning to block on the queue once more.

+ A Tx thread that repeatedly enters the Blocked state for 500ms. On exiting the blocked state the Tx thread sends a value through the queue to the Rx thread (causing the Rx thread to exit the blocked state and blink the LED).

Blocking for a finite period allows the kernel to stop the tick interrupt
and place the STM32 into sleep mode.

In this example, not used GPIO's are configured to analog, this help to reduce
the power consumption of the device

However after I started the program. I get SWD communication failure on the ULINK2.

How can I recover from this? Thanks

Parents
  • It's expected to get communications failure when running power-save functionality. So traditional routes are to make the code better behaving during the development phase.

    - maybe check a GPIO and not activate low-power features unless the pin says "ok".

    - add a couple of seconds of delay at program startup, to give time to connect and stop the program before it disconnects.

    - maybe check the supply voltage and avoid low-power if the device has "charger connected".

    The above methods applies to all kinds of code that will play around with oscillators or power modes.

    If a device has already been programmed with a problematic software, then it's time to check what potential options the specific processor might have for trigging internal boot loaders, booting from alternative memory, connecting while in reset or similar. In short - if the chip manufacturer have implemented some ways to "unbrick" the processor.

Reply
  • It's expected to get communications failure when running power-save functionality. So traditional routes are to make the code better behaving during the development phase.

    - maybe check a GPIO and not activate low-power features unless the pin says "ok".

    - add a couple of seconds of delay at program startup, to give time to connect and stop the program before it disconnects.

    - maybe check the supply voltage and avoid low-power if the device has "charger connected".

    The above methods applies to all kinds of code that will play around with oscillators or power modes.

    If a device has already been programmed with a problematic software, then it's time to check what potential options the specific processor might have for trigging internal boot loaders, booting from alternative memory, connecting while in reset or similar. In short - if the chip manufacturer have implemented some ways to "unbrick" the processor.

Children
No data