Although BUTTONS_ACTIVE_STATE declared as 1, the hal_buttons_init(button_event_handler) yields an event when the input sees a high to low transition in stead of a low to high transition.
Is this a bug in the softdevice or in another module?
Although BUTTONS_ACTIVE_STATE declared as 1, the hal_buttons_init(button_event_handler) yields an event when the input sees a high to low transition in stead of a low to high transition.
Is this a bug in the softdevice or in another module?
Hi,
Did you define BUTTONS_ACTIVE_STATE to '1' in your board header file to make sure it doesn't get redefined (pca10040.h, pca10056.h, etc? I just wonder if the pin configuration may have been overridden by a different module such as the Board Support Package (BSP). Also, is hal_buttons_init() from an SDK module?
Hi,
Thanks for your time to answer my question. I use the light dimming example from the SDK for mesh. The project has been adapted to work with our custom board.
Changes are a specific header file in the SDK boards folder and the project options preprocessor definitions removed the demo board definition and included the CUSTOM_BOARD_INC=myboardheaderfilename. In this myboardheaderfilename.h file the BUTTONS_ACTIVE_STATE is set to 1 and BUTTON_PULL set to NRF_GPIO_PIN_PULLDOWN. Two buttons are defined. The push buttons are connected between the GPIO and supply with an optional external pull downs on the GPIO pins.
Hi,
I'm not that familiar with the mesh examples, but it should be fairly similar to the regular SDK examples. To confirm the pin configuration is not overridden I would suggest that you read out the GPIO pin configuration with your debugger (NRF_GPIO->PIN_CNF[pin number]. Or have you done this already?
Bug found in simple_hal.c of the mesh SDK (v3.2.0). It is just forced low there without taking into account the setting in the board header file.
See line 67.