STM32F3 Discovery HARD faults at gpio_init

Hi,

Is there a build option to prevent the inclusion of the GPIO init code? Running on my STM32F3 Discovery board, I always get a HARD fault trap at the line port->MODER &+ ~(0x3 << (2 * pin_num)); in function gpio_init()

For what I’m doing I don’t need the GPIO stuff.

I also don’t need the UART - can I prevent this from being included too as my code is hanging waiting for a serial response that it’s never going to get? I suspect a printf() somewhere in the code base is causing this because I’m not using this function in my application code.

I’m using the RIOT OS master from 2017-07 and tried using the latest but that caused me more problems am I’m quite a tight deadline.

TIA,

Richard.

Hi @RicoUK,

Since 2017-07 quite a lot has changed, so maybe my suggestions do not apply, you can remove all printf output by including USEMODULE += stdio_null. This in the latest master prevents inclusion of uart:

BOARD=stm32f3discovery USEMODULE=stdio_null make -C examples/hello-world/ info-module
auto_init
board
core
core_init
core_msg
core_panic
cortexm_common
cortexm_common_periph
cortexm_fpu
cpu
malloc_thread_safe
mpu_stack_guard
newlib
newlib_nano
newlib_syscalls_default
periph
periph_common
periph_gpio
periph_init
periph_init_gpio
periph_init_pm
periph_pm
pm_layered
stdio_null
stm32_clk
stm32_vectors
sys

Regarding gpio, its included as FEATURES_OPTIONAL in Makefile.dep. So either comment out that line or in resent RIOT blacklist it:

FEATURES_BLACKLIST=periph_gpio BOARD=stm32f3discovery USEMODULE=stdio_null make -C examples/hello-world/ info-modules
auto_init
board
core
core_init
core_msg
core_panic
cortexm_common
cortexm_common_periph
cortexm_fpu
cpu
malloc_thread_safe
mpu_stack_guard
newlib
newlib_nano
newlib_syscalls_default
periph
periph_common
periph_init
periph_init_pm
periph_pm
pm_layered
stdio_null
stm32_clk
stm32_vectors
sys

I would highly suggest updating your RIOT version though, what kind of issues do you get when doing so? What are you trying to do?