This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

GPIOTE input pins dont work

Hello,

I use NRF52810 with SDK 14.2.0 and softdevice 112. I need to use 7 input pins,  but if I config more than 3 pins, all signals disappear.

GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS is setted to 7.
My configuration for each pins is like below:
	/**< INPUT. */
	nrf_drv_gpiote_in_config_t config_pwr = GPIOTE_CONFIG_IN_SENSE_TOGGLE(false);
	// BTN_PWR
	err_code = nrf_drv_gpiote_in_init(BTN_PWR, &config_pwr, PIN_EVT_Handler);
	APP_ERROR_CHECK(err_code);
	nrf_drv_gpiote_in_event_enable(BTN_PWR, true);

Parents Reply Children
  • If you use one of the examples with BLE, then you probably see some calls to NRF_LOG_INFO(); in the project, do you?

    What is the following defines set to in your sdk_config.h:

    NRF_LOG_ENABLED
    NRF_LOG_BACKEND_UART
    NRF_LOG_BACKEND_RTT

  • Yes. I have this function and log_init(), but dont undestand, how it can help me. 

    // <h> nRF_Log 
    
    //==========================================================
    // <e> NRF_LOG_BACKEND_RTT_ENABLED - nrf_log_backend_rtt - Log RTT backend
    //==========================================================
    #ifndef NRF_LOG_BACKEND_RTT_ENABLED
    #define NRF_LOG_BACKEND_RTT_ENABLED 0
    #endif
    // <o> NRF_LOG_BACKEND_RTT_TEMP_BUFFER_SIZE - Size of buffer for partially processed strings. 
    // <i> Size of the buffer is a trade-off between RAM usage and processing.
    // <i> if buffer is smaller then strings will often be fragmented.
    // <i> It is recommended to use size which will fit typical log and only the
    // <i> longer one will be fragmented.
    
    #ifndef NRF_LOG_BACKEND_RTT_TEMP_BUFFER_SIZE
    #define NRF_LOG_BACKEND_RTT_TEMP_BUFFER_SIZE 64
    #endif
    
    // </e>
    
    // <e> NRF_LOG_BACKEND_UART_ENABLED - nrf_log_backend_uart - Log UART backend
    //==========================================================
    #ifndef NRF_LOG_BACKEND_UART_ENABLED
    #define NRF_LOG_BACKEND_UART_ENABLED 1
    #endif
    // <o> NRF_LOG_BACKEND_UART_TX_PIN - UART TX pin 
    #ifndef NRF_LOG_BACKEND_UART_TX_PIN
    #define NRF_LOG_BACKEND_UART_TX_PIN 6
    #endif

  • Ok. And NRF_LOG_ENABLED is 0 or 1?

    The reason I ask is because it sounds like somewhere in the project the application "crashes", and the most common reason is because an APP_ERROR_CHECK(err_code) receives an err_code != 0.

    I don't know what HW you are testing on, but if you can connect an UART to it (if it is a DK, then it is connected to the on board Segger chip). Alternatively you can use the RTT backend if you have a segger debugger. You can use JLink RTT Viewer.

    The error handler is a very useful tool while developing, and one way is to monitor it via the log. It will let you know if APP_ERROR_CHECK() receives != 0.

    Another way is to define DEBUG in your preprocessor defines and set a breakpoint on line 73 in the app_error.c. But you may need to disable optimization to see what err_code it was and where it occured.

  • NRF_LOG_ENABLED is set.

    I can not use logging, because it`s a custom board,  and it hasnt got any external pin for uart logging and rtt logging with RTT Viewer doesnt work.

    I use define DEBUG, but I havent got hard error.

    Now, I trying to find mistake in the board. Maybe, it is not problem in the code.

  • LeonardPak said:
    and rtt logging with RTT Viewer doesnt work.

     Why? 

     

    LeonardPak said:
    I use define DEBUG, but I havent got hard error.

    Do you mean that it doesn't stop on line 73 in app_error.c?

    If you want to check whether it is the application that contains a bug or not, you can try your project on a DK, and just test by shorting GND to the pins that you use as input (remember to set pullup in the configuration, since the DK doesn't have external pull-up resistors).

Related