My custom board has only 1 button and I'm trying to detect 3 button clicks. The first click is waking up the device and the other 2 are configured as BSP_EVENT_KEY_0. I noticed people pushes the button between 0.2s to 0.4s after each click and the nRF52832 is not detecting the second click and the button has to be pressed a 4th time.
The IRQ prority is already at 2. I´m not sure if I should put it higher. My guess is that something in the main has higher priority and it is ignoring the bsp event
The only problem i have is when the device is sleeping. When the device is advertising the interruptions work fine. Any idea what is happening?Here is my main,
// Initialize the async SVCI interface to bootloader before any interrupts are enabled.
err_code = ble_dfu_buttonless_async_svci_init();
NRF_LOG_INFO("GWi DFU Application started.");
// Enter main loop.
nrf52832 custom board
The BSP uses the app_button library who has implemented SW debouncing by setting an app_timer to trigger a callback after 50ms where the app_button library will check to see if the button is still pressed. If the pin event is triggered before the 50ms has expired the app_button library will reset the app_timer. This might cause you trouble if the button signal is extremely bouncy. I would scope the button signal to check for noise issues and log the button press patterns of good vs bad operations. This will give us valuable insight into how the application responds to the button presses.
Sorry for the late reply, It doesnt seem to be the problem because once the device is awake I can press the button as fast as i can and it detects every single click. The issue is just the first half second after waking up.
Hmm, my best guess is that something is blocking the CPU from executing. Maybe the starting of the LFXO as it can take a few hundred ms. Do you mind sharing a project that we can use to recreate your issue? I suggest you strip out seemingly unrelated part of your code until the issue disappears as that will help us narrow down where the issue originates.
Hello, I posted the code as private. Evn tho i don´t think it is necessary for you to check it. I think i found the problem. After doing some changes I left the main with the following fucntions:
After doing some research i found out the issue is the nrf_sdh_enable_request takes too long executing. Sadly the guy didnt post how he solved it. Do you have any idea what is going on?
This is resolving the issue
#define NRF_SDH_CLOCK_LF_SRC 0 // I was using 32MHz XTAL#define NRF_SDH_CLOCK_LF_RC_CTIV 16#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2#define NRF_SDH_CLOCK_LF_ACCURACY 1
How will this affect the nRF52 behaviour?