TWI init conflicting with BLE initialisation calls

[sd]

Hello. I've used the design template that initialises everything for Bluetooth communication. These are the initialisation calls made in main():

// Initialize
leds_init();
timers_init();
gpiote_init();
buttons_init();
ble_stack_init();
scheduler_init();
gap_params_init();
advertising_init();
services_init();
conn_params_init();
sec_params_init();
    
// Start execution
timers_start();
advertising_start();

I then add a TWI init call from the "TWI master" example, but that hangs the chip (nRF51822) during the execution of the TWI initialisation routine. If I comment out some of the other initialisation calls, like so

// Initialize
leds_init();
timers_init();
gpiote_init();
buttons_init();
//ble_stack_init();
scheduler_init();
//gap_params_init();
//advertising_init();
services_init();
//conn_params_init();
sec_params_init();
    
// Start execution
timers_start();
//advertising_start();

twi_init() does not hang, and I'm able to talk to my peripheral over the TWI bus. Before I go investigate more closely why this happens, I was wondering if anyone else has experienced this before, and what might be a possible solution. I'm using the pin assignment from the example code if that's relevant:

#define TWI_MASTER_CONFIG_CLOCK_PIN_NUMBER (24U)
#define TWI_MASTER_CONFIG_DATA_PIN_NUMBER (25U)

[Håkon Alseth]

Most likely, its not the pin numbering that is making the example not work. Have you tried debugging and see what happens?

Most likely, you are getting an assert somewhere. If you comment in the assert handler, you are able to read out which line/file/error code you are getting:

void app_error_handler(uint32_t error_code, uint32_t line_num, const uint8_t * p_file_name)
{
    nrf_gpio_pin_set(ASSERT_LED_PIN_NO);

    // This call can be used for debug purposes during development of an application.
    // @note CAUTION: Activating this code will write the stack to flash on an error.
    //                This function should NOT be used in a final product.
    //                It is intended STRICTLY for development/debugging purposes.
    //                The flash write will happen EVEN if the radio is active, thus interrupting
    //                any communication.
    //                Use with care. Un-comment the line below to use.
    **ble_debug_assert_handler(error_code, line_num, p_file_name);**

    // On assert, the system can only recover on reset
    **//** NVIC_SystemReset();
}    
}

[Håkon Alseth]

Wow, that was unreadable. Sorry for this. Here's a small "howto" on getting assert info:

1. Comment out the nvic_systemreset
2. comment in the "ble_debug_assert_handler"

[sd]

Thanks for the quick reply! I've made the changes, and commented ble_stack_init() back. In the debug session, it gets stuck on the following:

0x00014214 E7FE B HardFault_Handler (0x00014214)

Is this the right place to look for the assertion? What does this mean, and where would be a reference that I can look up a meaning ;)?

[Håkon Alseth]

Did you add the "sd_twi_hw_master.c" file? A hard-fault can be triggered by many things, but most likely it's due to accessing peripherals that are blocked or restricted by the softdevice (S110 spec, chapter 8 for full overview).

Try inserting breakpoints and single-step through to find where you are triggering the HardFault.

[sd]

I'm including the "twi_hw_master.c" file. Is "sd_twi_hw_master.c" different? Where is it found (can't find it in the package)? (I'm new to this dev environment and BLE, so be explicit where possible.)