Handling Unused/Floating MDot pins.

[Ajay K]

We are seeing a lot higher current draw than previously and based on the stm32 web site, and suggestions it was suggested we need to handle the unused/floating pins. The suggestion was to configure all the unused pins to Analog input with no pull. We have configured most of the unused pins into Analog input pins and we do see an improvement in the overall power draw, but still is high. However here is a list of GPIO PINS, I am not sure if the MDot library is using or not? I wanted confirmation as to which PINS in the list below is not being used by the MDot Library that we can further convert to Analog input safely, to prevent any more floating pins.

//JTAG pins, we are not using it our custom hardware, can these be converted to Analog inputs as well?
26 PA14 JTMS-SWCLK STMicro – JTAG Clock /Serial Wire Debug Clock
27 PA13 JTMS-SWIO STMicro – JTAG Data I/O /Serial Wire Debug Data
28 PB4 JTMS-nRst STMicro – JTAG reset
29 PB3 JTDO-SO STMicro – SWO – Trace View

//are these pins being used by the mdot library? Can these pins be configure //as analog input?
PC_12 SPI3_MOSI SPI serial data
PC_11 SPI3_MISO SPI serial data
PC_10 SPI3_SCK SPI clock
PC_6 SPI3_CS SPI chip select
PC_7 FLASH_HOLD#
PC_8 FLASH_WP# Flash write protect
P88 Flash_WPn 10K PD //I don’t understand which pin this is?

//Looks like LORA Related PINS and currently being used by the mdot Library?
PC_0 LORA_RESET
PC_2 LORA_RXCTL
PC_3 LORA_TXCTL
PB_5 LORA_DIO0
PB_6 LORA_DIO1
PB_7 LORA_DIO2
PB_8 LORA_DIO3
PB_9 LORA_DIO4
PB_10 LORA_DIO5
LoRa/SPI2
PB_12 LORA_NSS
PB_13 LORA_RXCTL
PB_14 LORA_MISO
PB_15 LORA_MOSI

Also the code we are using to configure the unsed pins to analog inputs is as shown below. Is this the right way to implement it with mDot library 3.1.0?

GPIO_InitTypeDef GPIO_InitStruct;
 
//PA_0,PA_2,PA_3,PA_4, PA_5, PA_6, PA_7, PA_11,PA_13, PA_14  to analog nopull
GPIO_InitStruct.Pin = GPIO_PIN_0 | GPIO_PIN_2 | GPIO_PIN_3 | GPIO_PIN_4 | GPIO_PIN_5 | GPIO_PIN_6 |GPIO_PIN_7 |GPIO_PIN_11  |GPIO_PIN_13 | GPIO_PIN_14 ;
    GPIO_InitStruct.Mode = GPIO_MODE_ANALOG;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

Thanks,
Ajay

[Ajay K]

Any thoughts on this?

Thanks,
Ajay

[Jason Reiss]

Pins put to analog are shown in the AT Firmware
https://os.mbed.com/teams/MultiTech/code/Dot-AT-Firmware//file/35c201bc5205/CommandTerminal/CommandTerminal.cpp/

Also in the dot examples
https://os.mbed.com/teams/MultiTech/code/Dot-Examples//file/76f8a75ed3ec/examples/src/dot_util.cpp/

Does this answer your questions?

[Ajay K]

Hi Jason,

Thanks for taking the time to respond and provide the examples of how to handle floating pins. In the example, as described a 4 step process.
1) Save the IO State.
2) Configure the pins to Analog Input and no pull
3) Sleep
4) Restore the IO State.

I am not sure I understand the save and restore IO State? Don’t we want to to permanently configure the unused external pins to analog input? Also I believe for the MDot there is no concept of deep sleep, even if we set that flag to true while going to sleep it has no effect correct and We use just RTC wakeup mode and no wake pins in our custom firmware.

Also below is a list of the external pins we are using on our custom hardware, do we need to configure those pins to analog input, no pull before going to sleep?

PA_9 (USBTX)
PA_10 (USBRX)
PA_4 (Digital In)
PA_8 (I2C_SCL)
PC_9 (I2C_SDA)
PA_1 (Digital Out)
PB_1 (Digital Out)

Thanks,
Ajay

[Ajay K]

Any thoughts?

[Leon Lindenfelser]

Hi Ajay,
For the STM32, in isolation, setting all GPIO to “analog input no pull” will achieve lowest power consumption. However, you need to consider the attached components on your external I/O. Early on, we discovered some unexpected power draw unless certain pins were in a specific state. For instance, one component required pull down resistors on it’s SPI clock and MOSI pins in order for it to achieved its advertised lowest power in sleep mode. For cases like yours, where you have external components attached, we provide sleep versus deep sleep. In sleep mode we don’t set the external I/O to analog input no pull (in deep sleep we do). That allows the user to configure the external I/O, during sleep, as they see fit without interference from our library. If deep sleep is not getting to the expected low power level, you will need to sleep instead and configure the external I/O appropriately to achieve lowest possible current draw.
Kind regards,
Leon

[Author]

Posts