is there any other way to reduce current intake?
- One way is i turned off All the GPIO Pins. (This helped a lot)
But I need to know is there any other Things which can be turned off?
Thanks in advance
Please find below some hints to lower the power consumption:
- run code from RAM instead of the FLASH and put the FLASH in power down mode
- configure not used IO lines to analog mode
- use clock gating for not used peripherals
- lower the system frequency and clock frequencies on all buses
- decrease output max speed on IO lines configured to output
- replace CPU managed data transfers to DMA ones
I have few more question, pardon me if I sound too naive.
- If I run the code from RAM, everytime I unplug the power or the reset the board, the code has to reflashed to the board right?
- I have already configured the un-used to analog mode
- "use clock gating for not used peripherals"(Could you help me understand this more?, may be a sample code would help)
- "lower the system frequency and clock frequencies on all buses"(Could you help me understand this more?, may be a sample code would help)
- The IO lines are already set to lowest possible frequency
- "replace CPU managed data transfers to DMA ones" (I'm using all volatile variables in my application. Can you help me with some sample code?)
Hi Shivananda Halladamath,
Please do not worry, you are not sound naïve.
Let me answer to your questions (I will number them for easier tracking later).
1. In case of lost of power supply content of RAM is unpredicted and it should be written there again. In case of your code, you should prepare a procedure in your FLASH memory (which will be executed on each repowering the device) which would copy necessary part of the code to SRAM.
2. ok, but please be careful on PA13, PA14 as those pins are used by swd debugger. The best is to configure them as SWD ones (in stm32cubemx you can select this option within SYS peripheral) to be sure that your debugger will be able to connect to MCU. In case you forget it, you can still start your debug session, but the debugger should be connected in "connect under reset" mode and it should have connected its reset line to NRST pin of the MCU to control reset of the MCU.
3. clock gating is simply disconnecting the clock to given peripheral on the bus (APB, AHB). By default after the reset most of the peripherals (except FLASH, SRAM, NVIC) have the clock gated and you need to connect it before you perform any write to peripheral registers. To connect bus clock to peripherals you are using function (macro) __HAL_RCC_GPIOC_CLK_ENABLE() : to disconnect you are using functions (macros): __HAL_RCC_GPIOC_CLK_DISABLE(); . More information you can find in Reset and Clock Configuration section within reference manual (or RCC section in the library)
4. By default after the reset each STM32 is clocked by one of internal RC oscillators without PLL. It is not more than 16MHz, so usually we need higher frequencies, thus we are enabling PLLs, selecting external crystal as a clock source. Higher frequency on the core, buses mean higher current consumption. In your application you should analyze which frequency is optimum for each of peripheral you are using and configure all the prescalers to have those values. You can use for this purpose STM32CubeMX application, there in Clock Configuration tab you can see all the relations among clocking system in you STM32.
You can refer to PWR section in stm32f0 cube library. For stm32f091rc based nucleo-f0 board you can find example within the path:
6. DMA is used to copy some data from peripherals to memory in regular time slots without intervention of CPU. You can find a lot of examples within HAL library of your MCU. In example for STM32F091RC family those can be found within the paths (some examples, as there are much more on most of the peripherals):
Quick question. the paths which you have specified. is it the location where CubeMx is installed in my C: drive? because I cant find this path there
In CubeMX go to Help -> Updater Settings, and then looks at where you've pointed the "Repository Folder", this is where the tool downloads and unpacks the source trees and examples.
The F0 is from 2012 uses a Cortex-M0, the L0 is from 2014 use a Cortex-M0+, not sure I see details about the process geometry, but the L series parts target low power, battery powered applications.
Look at your own circuits. Anything that will draw static current.
Any compelling reason to be using an F0 rather than an L0? Check for pin compatible substitutes.
Find the device the the minimum RAM required.
Speed and performance doesn't scale linearly above 24 MHz
There's no compellign reason as such. I'm new to STM boards. I had to create an IoT node, hence I randomly selected F0 (Arm Cortex M0). is there any documentation which would help me in understanding which board suits the best for my application.
Also if F0 is not the right choice, I would like to know why it's not the right choice? from Power consumption Point of view.
Retrieving data ...