TWI init conflicting with BLE initialisation calls

RE: TWI init conflicting with BLE initialisation calls

Håkon Alseth — Tue, 16 Jul 2013 11:24:07 GMT

This file is something we at tech support have modified to make it softdevice compatible. I have pushed this to the R&D team to have them integrate a "softdevice" friendly library for all peripherals that are using restricted features (like PPI/random number generator etc).

All peripherals that are blocked/restricted or open are shown in the S110 specification, so when you get an error like this, you'll have to make sure that you are doing something "legal" in terms of which peripheral you are accessing.

The TWI is open and can be accessed directly, but in this case it's a couple of PPI channels that are being assigned inside the TWI library, which is very hidden and thats not fortunate.

RE: TWI init conflicting with BLE initialisation calls

sd — Tue, 16 Jul 2013 11:07:18 GMT

YES! It's working now! Phew. I was afraid of this being a huge time sink, so thank you for your patience and prompt replies! (If I didn't go asking stuff on this forum, how would I have known that this file is needed and where to get it?)

RE: TWI init conflicting with BLE initialisation calls

Håkon Alseth — Tue, 16 Jul 2013 11:01:34 GMT

Hi,

I uploaded it in this case: https://devzone.nordicsemi.com/index.php/best-place-to-get-started

RE: TWI init conflicting with BLE initialisation calls

sd — Tue, 16 Jul 2013 10:58:43 GMT

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.)

RE: TWI init conflicting with BLE initialisation calls

Håkon Alseth — Tue, 16 Jul 2013 10:52:50 GMT

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.

RE: TWI init conflicting with BLE initialisation calls

sd — Tue, 16 Jul 2013 10:49:56 GMT

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 ;)?

RE: TWI init conflicting with BLE initialisation calls

Håkon Alseth — Tue, 16 Jul 2013 10:31:33 GMT

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

Comment out the nvic_systemreset
comment in the "ble_debug_assert_handler"

RE: TWI init conflicting with BLE initialisation calls

Håkon Alseth — Tue, 16 Jul 2013 10:29:56 GMT

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();
}    
}